-----Original Message-----
From: Malachi de Ælfweald [mailto:malachid_at_gmail.com]
Sent: Thursday, March 02, 2006 11:42 AM
To: users_at_jaxb.dev.java.net
Subject: Re: JAXB compilation plugin
I see that you have an unused PatternFilenameFilter.java
However, I have to question this approach...
[jon] Me too ;-)
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.
[jon] I agree that schemas should be placed in a package structure that
matches the source, but the schemas and bindings and any other resource file
should not live in the java tree. Instead the schemas and code should live
in the parallel packages at distinct source roots. For example
\src\main\java\com\sun\foo\someclass.java
\src\main\schemas\com\foo\somecorresponding.xsd
When assembling a jar, yes the class files live in the same location as
the xsd, but the java and xsd sources should be kept separate as a best
practice.
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).
[jon] I was not happy with PatternFilenameFilter because it does not
recurse directories. This is needed. Instead of coding this I was looking
existing code that supports tree traversal with regular expresions. Its
fairly easy to write, but why reinvent the wheel. If you find something
lets use it, I'm still looking.
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.
[jon] I thought there was a correlation between each xsb and xsd file, but
there isn't. This makes it easy then. A technical problem here is XJC2Task
only has a setBinding and a setSchema method. For each schema the plugin
finds it calls setSchema and setBinding. With this API how does one call
setSchema then setBinding with multiple binding files? There are
addConfiguredXXX methods. Perhaps this is what they are for?
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.
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.
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
>> 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.