On 3/1/06, Jonathan Johnson <jonjohnson_at_mail.com> wrote:
>
>
>
> In theory, we could set it up so that they could use either format fairly
> easy....
>
> What if we did a Java MOJO that had all the XJC configuration settings as
> options -AND- had an optional <xjcTask>xjc-build.xml</xjcTask>
> The only difficulty would be in ensuring that the XJCMojo adds any new
> XJCTask configurations...
>
>
> Offering more than one way to do the exact same thing may confuse
> people. KISS principle. People may also try to combine the the two setting
> styles. Its also more code to maintain.
>
That's true.
> If you consider this example...
>
> <xjc target="src" removeOldOutput="yes" package="org.acme.foo">
> <schema dir="schema" includes="*.xsd" />
> <depends dir="schema" includes="*.dtd" />
> <produces dir="build/generated-src/org/acme/foo" includes="**/*" />
> </xjc>
>
> This just does not seem to make sense in a Maven environment because:
>
> 1. Items like removeOldOutput and package maven users expect to set them
> like so <removeOldOutput>true</removeOldOutput>
>
I agree.
2. Many of the settings in Maven are defaulted to standards. The M2
> plugin defaults source to be "schema" and *.xsd. So for most people they
> never have to configure that. With ant you are forced to define all
> directories and files. It seems like a step backward by requiring all the
> ant settings that are automatic in maven. Maven gets your away from that
> with a defaulted directory layouts and assumptions.
>
I had mine defaulting to a separate directory for the schemas originally as
well -- although I have changed that now. I now have my XSD files in the
same directories as my source code (much like the xjc jar does after
deployment). It finds all XSDs in the directory and all subdirectories, so
that works well. Also, that makes the resources configuration (for putting
extra files in the jars) easier in the end since they are already in
package-oriented directory structure.