directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <fel...@apache.org>
Subject Re: apacheds-maven-plugin and ApacheDS 1.5.7
Date Tue, 28 Sep 2010 18:44:13 GMT
-----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
> <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 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-----

Mime
View raw message