-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyiN30ACgkQ2lZVCB08qHFsngCg7fvgDY9My2Wgi5tQLE6MVHTi f3IAoMeUvGC2KD2AmbzjHnZy9kIUX6Od =qfSr -----END PGP SIGNATURE-----
