Jonathan Johnson wrote:
>>> The reason it takes a String and not File nor URL is because it can be
>>> both URL or a file. I clarified the xjcTask.html in the docs folder to
>>> say accordingly.
>
> Why not have the method just take a URL type and require the "file://"
> protocol for local files? Leaving it as a loose string leaves it open to
> lots of validation problems. UniversalRL does not have to mean just remote.
If this wasn't an Ant task I would have done so. URL conceptually
subsumes File, as you correctly pointed out.
However, in Ant, specifying a file in a URL format is quite
inconvenient. For example, when someone writes this:
<xjc schema="foo/bar.xsd" />
he's expecting it to resolve against the project base directory. If I
declare setSchema to take URL, he would have to do it by himself, and
then convert that to File, which is hopeless.
So I think it's a necessary evil that it's taking String.
>>> I also updated javadoc.
> Just a suggestion... The XJC2Task has a bunch of missing comments from the
> javadoc. Also a few method names use non-standard naming and camel humps.
> setXexplicitAnnotation, setDestdir, setFailonerror. I have other questions
> about the API but was hoping a revised javadoc would answer the questions.
> See
> https://jaxb-architecture-document.dev.java.net/nonav/doc/com/sun/tools/xjc/
> XJC2Task.html
I think these are also because of Ant. I thought if I declare it as
setDestDir, the user would have to say destDir="...", which is non
standard in Ant.
>>> What I actually meant to suggest was to use Ant's parser to parse DOM
>>> into Ant task invocation directly, and not programmatically calling
>>> XJC2Task methods.
>
> If we want it to look just like Ant then why not use the Maven to Ant plugin
> and invoke the Ant task to do XJC?
I think being able to use Maven has a lot of benefits. If I generate Ant
build.xml and then run, I'd lose those.
I thought there are a lot of configuration that's the same between Ant
and Maven --- such as specifying package name, verbosity, plugins,
additional options for plugins, etc. I think it makes sense to reuse the
same syntax in these cases.
Probably there are some cases where the syntax should be different (like
in Maven the output directory should come from Maven, not from the
configuration), but I still think that we can reuse a good portion of
the Ant syntax. It also allows us to avoid writing the parsing code.
> I was attempting a more M2 native approach by following the other M2 plugin
> configuration conventions. For Maven users it might be a step backward to
> following the exact Ant configuration. I think we should build on it an
> follow the Maven 2 approach for setting the configuration - keeping in mind
> that most users of Maven are migrating from Ant. I created a class derived
> from XJC2Task that took care of the Ant project and Ant logger problem.
> This way if things are fixed in XJC2Task or are added to XJC2Task then the
> Maven 2 plugin will hopefully inherit those improvements. It would be
> better to abstract all the XJC2Task Ant specifics and put the common
> behavior in a common adapter that both the Ant and Maven adapters can use.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com