Comments inline ;)
On 3/2/06, Jonathan Johnson <jonjohnson_at_mail.com> wrote:
>
>
> -----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 ;-)
>
Ok :)
>
> 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.
>
I can see that. Maven's docs say that there should be a "resources"
directory. Do you think we should use that, or do you think that the
XSDs/XJBs need their own "schemas" directory. I ask, because, what if they
are using DTD? That isn't technically schema, but should go in the same
place.
>
> 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.
>
Well, the problem with the PatternFilenameFilter was two-fold.
1) if checked file.getName() instead of file.getAbsolutePath() -- so I could
not do **/eld/**
2) it would have to return true for any directory (unless the case of #1
above) and then the routine it returned to would have to call it again for
any directories returned. Personally, I don't think I like that approach,
because what if I actually did intend to specify a directory instead of the
individual files?
> 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?
>
I had thought that as well. Also, per the previous email chain, I think we
might be considering the ability to specify setBinding(File directory) as an
option like we do with setSchema...
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.
>
>
> 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.
> >
> >
> >
>
>