users@jaxb.java.net

Re: JAXB compilation plugin

From: Malachi de Ælfweald <malachid_at_gmail.com>
Date: Sat, 4 Mar 2006 21:57:54 -0800

Doh! You're using the XJC2Task, right. Nevermind.

On 3/4/06, Malachi de Ælfweald <malachid_at_gmail.com> wrote:
>
> Why is there already a dependency on Ant-1.6? I don't have a dependency on
> Ant in my build.
>
>
> On 3/4/06, Jonathan Johnson <jonjohnson_at_mail.com> wrote:
> >
> > Instead of the current, problematic PatternFilenameFilter we can just
> > use
> >
> > org.apache.tools.ant.types.FileSet
> >
> > to handle the ** patterns and searching
> >
> > expecially since there is already a depedency on
> >
> > <dependency>
> > <groupId>ant</groupId>
> > <artifactId>ant</artifactId>
> > <version>1.6 </version>
> > </dependency>
> >
> > This pattern matching will be used for
> >
> > String[] includeSchemas
> > String[] excludeSchemas
> > String[] includeBindings
> > String[] excludeBindings
> >
> > (note to self, duh!)
> >
> >
> >
> >
> > So, a couple questions:
> > > 1) Feasibilty of modifying XJC to allow a -bd (bindingDirectory) that
> > > would do a recursive subdirectory search just like it does for XSDs
> > > [jon] Yes - this needs to be added.
> > > 2) Changing the MOJO to iterate through subdirectories and compare
> > > all files in subdirectories to the specified pattern (which I assume would
> > > default to '**/*[\.][xX][sS][dD]' and '**/*[\.][xX][jJ][bB]' respectively...
> > >
> > > [jon] Yes - this needs to be added. Was hoping to find some 3rd party
> > > utility to do this. oro GlobFilenameFilter was just a stop gap.
> > >
> >
> > #1 might eliminate the need for #2... but... the idea of excluding
> > **/eld/** or including **/v2/** is hard to ignore...
> >
> > 3) easiest way for the user to specify multiple ignore options... like
> > > "**/eld/**" to ignore subdirectories or simply "oldSchema.xsd"
> > > [jon] Yes - the binding and schema should both have include and
> > > exclude regular expressions. All four would assume 'schemaDirectory' as the
> > > root.
> > >
> > > For #3, it seems like the easiest solution would be for the @parameter
> > > to be a String[] or ArrayList<String> then compile them internally.
> > >
> > > Also, in my case, the configuration is in the top-level pom.xml and my
> > > submodules (via reactor) don't actually specify anything. I think the
> > > default behavior is that it is going to rebuild the Pattern for each
> > > submodule. I don't see any realistic way to avoid that.
> > >
> > >
> >
>