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? > >>> I see in trunk that ResourceMap now accepts a system property that can >>> be set to the locations of JARs to load to skip classpath scanning. >>> This doesn't completely help, either, since I'm hesitant to do things >>> with global side effects (like set System properties) in the middle of >>> a Maven plugin. I can come up with a list of relevant JARs by trawling >>> the artfact information in my plugin, so if there were a way to pass >>> that list directly to ResourceMap I'd prefer to use that. I can write >>> that up as a patch, if you're interested. >> >> yes IMO this is the best way to go, getting the jar name is straight forward. >> The artifact name is fixed (atleast till the 2.0 version) i.e >> 'shared-ldap-schema' >> and we can get the version number from the server version the plugin depends >> on >> e.x 0.9.19 > > I don't even need to do that. There are some maven plugin utility APIs > that can generate the list of artifacts of a given type straight from > the project metadata, and I can throw the entire list of dependency > JARs at ResourceMap. so the 'metadata' being the index file that you mentioned above? > > -o >
Kiran Ayyagari
