I have plugins for apache directory 1.5.0 and 1.5.1 apparently
working for geronimo 2.1-SNAPSHOT (trunk). I also tried one of them
against the proposed 2.0 binaries and they appeared to work. I've
been testing using LDAP Studio (I think version 0.8.0) and can
connect, view entries, and edit stuff.
There are some little questions left that I'm not quite sure how to
deal with:
How should we name/version these plugins? It looks like there are 2
sets of numbers involved, that from apacheds and that from geronimo.
I've ignored this so far and called everything 2.0-SNAPSHOT (both
versions) but this is obviously not satisfactory. Maybe we should
use a numbering scheme like in the specs? directory_1.5.0-2.0 means
it uses apacheds 1.5.0 and more or less corresponds to the 2.0
geronimo server?
Do we need a version for apacheds 1.0.x? I think there have been
major advances in flexibility in apacheds between 1 and 1.5, but they
claim 1.5 is a "new features" release not a "really stable" release.
Personally I'd much rather work on triplesec than another plugin
version but if there is actual demand and no other takers I'll look
at a 1.0.x plugin.
How much flexibility do we need to start with? Right now after (or
before) you install the plugin you can put your own apacheds
server.xml file in var/directory/server.xml to configure the server.
However this doesn't let you change the set of bootstrap schemas or
such stuff. I'm inclined to leave such features until we know more
about how it's used, but if anyone has clear ideas please speak up.
I've already found and fixed some problems in the plugin installer,
and we'll probably find more. Right now if you want to run these on
geronimo 2.0 (which does not have the plugin installer features) you
need to (after suitably updating your geronimo-plugins.xml, which for
experimentation you are probably keeping in your ~/.m2/repository)
you need to install the plugin, which will fail with file copying
errors, and then copy server.xml out of the installed car file into
var/directory/server.xml and then start the configuration (such as in
the console).
I'm not thrilled with how the car-maven-plugin is filling in all the
dependency versions in the target plan, but that is obviously a
separate issue for the car-maven-plugin.
thanks
david jencks
