Dan,
Sorry, I should have mentioned that the requirement to have the classes in
the \ext directory was only for the RI beta. I beleive it was going to be
fixed in the FCS version.
Marty
----- Original Message -----
From: "Dan Lange" <dlange02_at_HARRIS.COM>
To: <JAXB-INTEREST_at_JAVA.SUN.COM>
Sent: Monday, February 24, 2003 10:08 AM
Subject: Re: Using javaType to map custom classes
> I put MyName.class in a jar file and put the jar file in the jre/lib/ext
directory of my java installation. That enabled xjc to see MyName in the
classpath, and I was able to complete code generation.
>
> I am concerned that this will not be an acceptable solution for a
production system, however. It forces your build process to be a complex
multi stage affair:
> 1) Compile your simple type java classes.
> 2) Create a jar file from your simple type java classes.
> 3) Put the jar file into your lib/ext directory.
> 4) Run xjc
> 5) Compile your simple type, generated, and XML user code.
> 6) Put the simple type, generated, and XML user code into a jar file.
>
> Worse, jar files that you put in the lib/ext directory are available to
all users of that java installation, and take precedence over files in the
classpath. The build process should not be manipulating this directory.
>
> My CM admin is going to throw a fit when I ask him to torture our build
process in this way.
>
> I would much prefer if either:
> a) xjc didn't check for the existence or method signatures of custom
classes.
> pros: The build process is limited to steps 4,5,6 listed above.
> No need to put things in the extensions directory at build time.
> cons: If the javaType tag in the schema references an invalid class or
> method name, the error won't show up when xjc is run. It will
> show up when the generated code is compiled.
>
> b) xjc checked custom classes, but looked in its own classpath (or one
specified as a command line argument), not the extensions classpath.
> pros: The build process is limited to steps 1,4,5,6 listed above.
> No need to put things in the extensions directory at build time.
> cons: None
>
> Note that in any case, there is no guarantee that the generated code will
be compiled in the same environment that it is generated, so there is no way
to guarantee that it will always compile.
>
> I consider the dependency on the extensions directory to be a bug in the
beta implementation.
>
> Is there any way that this can be fixed in the next release?
>