I see that you have an unused PatternFilenameFilter.java
However, I have to question this approach...
I used to put all of my XSD files under src/conf and distributed them into
the root of the jar. As such, PatternFilenameFilter and GlobFilenameFilter
would both work well.
I noticed that the XJC jar had the binding.xsd under
/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd inside the jar.
This is actually really good because it prevent classloader problems of
finding the wrong one by some other company. I started to modify the
resources section of my pom.xml, and realized there was a much easier way.
I have now moved all of my XSD files directly into the source directory. In
the IDE, they show up as a resource in that package/namespace, and the
resources part of the pom.xml automatically can copy them into the correct
directory without any sophisticated filename mapping.
For JAXB, I just tell it to compile all schemas it finds under the source
directory. It automatically finds them all recursively -- I don't have to
list anything other than the top level directory.
Both the PatternFilenameFilter and GlobFilenameFilter will fail on this
structure, because it doesn't iterate through subdirectories...
If we were to use the filename filter logic, I think we have to explicitely
iterate through subdirectories -- which would lead to modifying the
PatternFilenameFilter instead of using the GlobFilenameFilter (which
technically looks like it does the same thing).
But, while we are on this topic, we should consider the XJB files as well. I
am not using them, but I am sure many are.
According to the docs (
http://java.sun.com/webservices/docs/1.6/jaxb/xjc.html ) the order of the
XSD and XJB files on the command line don't matter --> ie: I read this to
mean that xjc just requires listing all the XJB files and doesn't require
specifying which XJB files go to which XSD files. Now, while this may be
easier for the XJC code, it is not necessarily the cleanest for the pom.xml.
It would be easier for the user if all XJB files were used (as is the case
with specifying a directory instead of a specific XSD on the command line)
-- with the ability to ignore speciifc XJB files.
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
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...
3) easiest way for the user to specify multiple ignore options... like
"**/eld/**" to ignore subdirectories or simply "oldSchema.xsd"
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.
Malachi
On 3/2/06, Jonathan Johnson <jonjohnson_at_mail.com> wrote:
>
> >> Have you had any problems building the plugin? It failed to download
> the ORO pom from
> >> http://repo1.maven.org/maven2/oro/oro/2.0.8/oro-2.0.8.pom<http://repo1.maven.org/maven2/oro/oro/2.0.8/oro-2.0.8.pom>
> >> which happens to be valid...
>
> Malachi - Thanks for helping out!
>
> The oro download works for me. More often than should the maven
> repository craps out. I find if you just try again it works. It appears
> the maven repository servers have traffic and timeout issues as downloads at
> 3am fly.
>
> Oro is needed for filename pattern matching
> org.apache.oro.io.GlobFilenameFilter. Not sure if this is the best
> apporach. I'm looking for a maven API or something that supports something
> like the ant fileset feature.
>
>
>