Kohsuke Kawaguchi wrote:
>
> Hi,
>
> We tried to reproduce this problem with Windows XP, but in our
> environment it worked. "jaxb-xjc.jar" has a manifest entry that look for
> ../../jwsdp-shared/lib/jax-qname.jar. Although it was broken up by line
> break, Java VM doesn't seem to be affected by it.
>
> When I renamed it to jax-qname.ja_, if starts to exhibit the problem you
> mentioned (ClassNotFoundError for javax.xml.namespace.QName)
>
> By default, JWSDP will install jax-qname.jar into the abovementioned directory,
> so it should be able to find the jar file. Is there any chance you moved
> those files, or can you think of any other potential step we need to
> take to reproduce the problem?
>
> I'm also curious if Mark Brouwer experienced the same problem when he
> invoked jaxb-xjc.jar directly. Mark?
>
Well I didn't experience any problems but I use jaxb-xjc.jar through the
Ant task (J2SE 1.4.1 Windows NT and Solaris).
I have a xjc task directory that contains the jaxb-xjc.jar file and all
the files it needs to do its work (dom.jar, jaxb-api.jar, jaxb-ri.jar,
xercesImpl.jar, jax-qname.jar, jaxb-libs.jar) and include this in my
build file by:
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath>
<fileset dir="${ant.home}/../xjc/lib" includes="*.jar"/>
</classpath>
</taskdef>
And moving from early access to FCS made no difference.
But I must also admit that the way the Class-Path is assembled in the
jaxb-xjc.jar is not my way of doing things, but that I guess is the
effect of bundling all the XML technologies as part of the JWSDP, which
IMHO has been a very bad decision.
While I'm at it, are there any plans to provide maintenance releases or
seperate releases of JAXB independent of the JWSDP?
--
Mark Brouwer