directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: apacheds-maven-plugin and ApacheDS 1.5.7
Date Tue, 28 Sep 2010 17:36:01 GMT
On Tue, Sep 28, 2010 at 10:49 PM, Owen Jacobson
<> wrote:
> On Tue, Sep 28, 2010 at 1:11 PM, Kiran Ayyagari <> wrote:
>> hi Owen,
>> On Tue, Sep 28, 2010 at 10:10 PM, Owen Jacobson
>> <> 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 . 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

View raw message