On Tue, Sep 28, 2010 at 2:44 PM, Felix Knecht <[email protected]> wrote: > On 09/28/10 19:36, Kiran Ayyagari wrote: >> On Tue, Sep 28, 2010 at 10:49 PM, Owen Jacobson >> <[email protected]> wrote: >>> On Tue, Sep 28, 2010 at 1:11 PM, Kiran Ayyagari <[email protected]> >>> wrote: >>>> hi Owen, >>>> >>>> On Tue, Sep 28, 2010 at 10:10 PM, Owen Jacobson >>>> <[email protected]> wrote: >>>>> Hi there, >>>>> >>>>> As you may have seen in another thread this morning, someone's asked >>>>> that I upgrade apacheds-maven-plugin to ApacheDS 1.5.7. This hasn't >>>>> gone as smoothly as I had hoped. >>>>> >>>>> ApacheDS 1.5.7's mechanism for populating the schema directory >>>>> involves trawling through every entry in the java.class.path system >>>>> property looking for JARs that contain schema files. The relevant code >>>>> is in org.apache.directory.shared:shared-ldap-schema:0.9.19 . Maven >>>>> doesn't use -classpath (or set java.class.path) when running plugins, >>>>> so this mechanism fails - the only JAR it finds is Maven's classworlds >>>>> bootstrap JAR, which obviously has nothing interesting in it. In fact, >>>>> this mechanism fails for any program that doesn't use the root >>>>> classloader to load ApacheDS. >>>>> >>>>> I think the only universally workable solution is to change the >>>>> packaging for the schema LDIF files so that instead of being scanned, >>>>> each JAR that contains schema files also contains an index file at a >>>>> known location (such as META-INF/apacheds/schema) listing all of the >>>>> schema files in that JAR. Unfortunately, that's a pretty >>>>> labour-intensive solution (it means anyone who adds a schema to >>>>> shared-ldap-schema or related artifacts has to remember to update the >>>>> index as well, or that someone has to tune the build to generate the >>>>> index file. I'm happy to set this up, if it turns out to be the best >>>>> solution. (As you can tell, I'm already fairly adept at extending >>>>> Maven. :) >>>> >>>> hmm, though it helps in reduced scan time this again suffers from the >>>> same class loading issue >>> >>> Not at all. shared-ldap-schema-*.jar is available in the classloader >>> ApacheDS is being launched with. By asking that classloader for a >>> resource with a known name (using >>> ClassLoader.getResources(schemaIndexPath)), we skip the scan entirely >>> and go straight to reading the files (also using >>> ClassLoader.getResource... methods). I can patch this up, if you want >>> a demonstration. :) >> hmm, I mean will it solve the issue the maven plugin has in finding >> the schema resources? > > Can't we add any jars in question (containing the ldif files) as a > plugin dependency in the plugins configuration section? So we would have > the sources. We could even pre-extract the ldif files from the dependent > jars into a <plugin><configuration><ldifDirectory>...</> directory and > then use them from this location.
I'm not willing to impose the use of dependency:unpack on users of apacheds-maven-plugin, which is what you'd have to use. Adding them to the plugin's dependency list is insufficient (they're already there, in fact - they're a transitive dependency of apacheds-all :), since ResourceMap looks specifically at the java.class.path system property, not at the classloader ApacheDS's classes are actually being loaded from. There's no guarantee that that classloader is enumerable, either, unfortunately. -o
