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.
> >
> >
>