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. :) 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. I don't think there's a good solution for supporting ApacheDS 1.5.7 in apacheds-maven-plugin as it stands, unfortunately. If anyone has any thoughts that don't involve temporarily faking the java.class.path system property, I'm all ears. -o
