directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: OSGi perspective, plus a few other things...
Date Tue, 19 Apr 2011 11:17:22 GMT

On 19 avr. 2011, at 03:11, Emmanuel Lecharny wrote:

> Hi guys,
> 
> yesterday we tried to deal with some existing issues related to the way we use OSGi.
There are a few that need to be improved or discussed. Here is a brain dump about those things.
> 
> 1) Currently, we have two modes. The first one is when the API is loaded into an OSGi
enabled application, and the secodn one is when we use the API in an application which is
not using an OSGi container.
> 
> In the second case, we use the StandaloneLdapCodecService to initialize Felix, if it's
not already done otherwie we just do nothing.
> 
> Beside the name (why is it a CodecService ? Because it just deal with the codec atm,
but at some point we will also load schema elements, so we need to find a better name), one
of the main issue is that the bundles are loaded only when they are put into a directory.
> 
> In shared, it's not an issue, but when we use an application which does not have an OSGi
container started, then we have to copy the bundles that are not loaded by default into a
special directory. I suggest we keep this mode, but that we also propose a mode in which the
list of bundles to load is provided, with their path, so we won't have to copy the bundles.

+1 but we'll have to see if it possible with Felix to link multiple locations or if a common
single-folder location is absolutely mandatory.
I don't know about that.


> 2) We have a list of packages to load in the StandaloneLdapCodecService class. If we
move, or rename, one of those package, we will get an error. Plus we will have to remember
to update this list if we add some new classes.
> 
> A TODO says that this list has to be generated from the Manifest. Yep. Let's do that
!

+1, I'll try to help in that area.


> 3) we have some issues in Eclipse, as we have to set some property in the command line
when running some of the tests. This is not convenient at all, but unless we find a simple
way to do it automatically, we are quite dead. I would suggest as a bare minimum that we document
this in the development guide.

To be more precise, a few system variables need to be appended to the VM arguments of a launch
configuration in Eclipse.
Here is an example:
> -Dcodec.plugin.directory=/Users/pajbam/Development/Apache/trunks/shared/integ/target/pluginDirectory
> -Dfelix.cache.rootdir=/Users/pajbam/Development/Apache/trunks/shared/integ/target
> -Dfelix.cache.locking=true
> -Dorg.osgi.framework.storage.clean=onFirstInit
> -Dorg.osgi.framework.storage=osgi-cache

Note: I'm not sure all of them are really mandatory.

It would be cool to find a way to add this automatically whenever a new launch configuration
is created (if that is possible).


> 4) We have to start thinking about transforming ApacheDS to be OSGi enbled. Not having
done this job makes things more difficult. We wll have to do it anyway, the question is :
why wasting time trying to workaround the issues we have, instead of spending this time to
do the job completely ?

That's a tough work but I guess it would also bring us some benefits. The OSGI-fication of
Shared was just a first step...


> I would like to get a API 1.0.0-M3 out asap now. A lot of work has been done since 1.0.0-M2,
and before moving to the next step, I think it would be a good idea to cut a new milestone.

Sounds good to me.
With the upcoming documentation on the API, we could even start to advertise about it on the
MLs.

> There is one more thing I think we should provide asap : a Apacheds-2.0.0-M1. Many users
are now complaining about the 1.5.7 bugs, and we have no way to get them happy, bt telling
them to patch the code themselves, something which is frankly tedious.
> This 2.0.0-M1 is not a feature not a code freeze, it's just a clear signal that we now
are ready to move toward to 2.0.0. The configuration has been completely reviewed, it will
depend on the 1.0.0 API, and many bugs have been fixed.

Sounds good to me too.
At least it brings a better signal for users.
Even if it nowhere near a RC or final version, users can get their hands on some new stuff
and see we've not been twiddling our thumbs.

> I have no idea about how much time we will have to spend on 2.0.0 before being able to
announce a RC1, but at some point, it's a bit frustrating to keep going at the current pace.
What has been done since January on the API has been just great. 3 releases have been delivered
(I'm including 1.0.0-M3), with a lot of cleanup, some big features addition, and it was a
pleasure to see things moving that fast. Lets follow the same path for ADS !

Agreed.

As soon as a first version of ApacheDS is released we could also follow the same path for
Studio (in addition to the proposed 1.5.4 bug fix release of the "stable but old" branch).


Regards,
Pierre-Arnaud

> 
> Thanks !
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
> 


Mime
View raw message