Mark Brouwer <mark.brouwer_at_virgil.nl> wrote:
> Nice features for the 1.0.1 release[1], I can't comment if all the major
> problems with the 1.0 release are gone now, for I'm still in the process
> of changing my build scipts.
>
> With the enhanced XJC Ant task I discoverd a bug, the documentation
> states that for the new 'up-to-date check' the task will put the schema
> and its bindings in the depends set. This is true for the schema but not
> for the binding (if it has been specified as an attribute) as can be
> seen if you run Ant with the verbose option. By adding the binding file
> as a nested element I fixed the problem. But according to what is being
> said in the documentation I think it is a bug.
Indeed. Thank you for finding that problem, and I fixed it. I also
confirmed that if you use nested <binding>, it'll be a part of the
<depends> set.
>
> [1] except for the fact the impl.runtime classes are generated and not
> part of a standard library. In our case we have a schema B that imports
> schema A. The impl.runtime source files are now generated in the package
> of schema B. The classes of schema A refer to the package of B, however
> all classes of schema B lives in a child class loader of the loader
> schema A. That means from the class loader of schema A its runtime
> clases are not visible. I realize this is not a standard situation but
> at least an option to specify where the impl.runtime classes are
> generated would seems to be a nice option. I can work around it with
> some extra lines of the build script, but I think having control would
> be a nice feature.
No problemo. Use the "-use-runtime" option.
regards,
--
Kohsuke Kawaguchi 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com