Here are the current ant dependencies in the maven 2 plugin code.
public class XJC2TaskAdapter extends XJC2Task
public class XJC2Task extends org.apache.tools.ant.Task
import org.apache.tools.ant.Project;
-----Original Message-----
From: Malachi de Ælfweald [mailto:malachid_at_gmail.com]
Sent: Sunday, March 05, 2006 12:53 AM
To: users_at_jaxb.dev.java.net
Subject: Re: JAXB compilation plugin
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.