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?