directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Jacobson <>
Subject Re: apacheds-maven-plugin and ApacheDS 1.5.7
Date Tue, 28 Sep 2010 19:24:32 GMT
On Tue, Sep 28, 2010 at 2:44 PM, Felix Knecht <> wrote:
> On 09/28/10 19:36, Kiran Ayyagari wrote:
>> On Tue, Sep 28, 2010 at 10:49 PM, Owen Jacobson
>> <> wrote:
>>> On Tue, Sep 28, 2010 at 1:11 PM, Kiran Ayyagari <>
>>>> 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?
> 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
> 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

There's no guarantee that that classloader is enumerable, either, unfortunately.


View raw message