Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4CA2377D.8040100@apache.org>
References: <AANLkTi=-QYedzbfWpsE850NTuqq9vvoJJ0Z5rnLzgbf_@mail.gmail.com>
	<AANLkTinK25rd68nqF6HKOh5fD6ZUfV5ikghz33LX3h-V@mail.gmail.com>
	<AANLkTi=ADtUTWTYQVJHbyHQQ_dN4aQ5np9SPQKTvkrhv@mail.gmail.com>
	<AANLkTinTtj26VV2Wmj8atNLOHnrQr-S3RFuggA_ACJ1_@mail.gmail.com>
	<4CA2377D.8040100@apache.org>
Date: Tue, 28 Sep 2010 15:24:32 -0400
Message-ID: <AANLkTinUBYwg++xBsUeH11=smA_pows31QbbON39m2qj@mail.gmail.com>
Subject: Re: apacheds-maven-plugin and ApacheDS 1.5.7
From: Owen Jacobson <owen.jacobson@grimoire.ca>
To: users@directory.apache.org, felixk@apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 28, 2010 at 2:44 PM, Felix Knecht <felixk@apache.org> wrote:
> On 09/28/10 19:36, Kiran Ayyagari wrote:
>> On Tue, Sep 28, 2010 at 10:49 PM, Owen Jacobson
>> <owen.jacobson@grimoire.ca> wrote:
>>> On Tue, Sep 28, 2010 at 1:11 PM, Kiran Ayyagari <kayyagari@apache.org> wrote:
>>>> hi Owen,
>>>>
>>>> On Tue, Sep 28, 2010 at 10:10 PM, Owen Jacobson
>>>> <owen.jacobson@grimoire.ca> 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