directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [IMPORTANT] Status of Apache Directory
Date Fri, 03 Nov 2006 12:57:15 GMT
Well done John.  What can we do to increase the update of this so others 
get involved with you to work on the OSGi angle?


John E. Conlon wrote:
> On Thu, 2006-11-02 at 14:14 -0500, Alex Karasulu wrote:
>> =========
>> OSGi Plan
>> =========
>> I have no idea what is going on with the OSGi work. 
>>  It seems like John 
>> Conlon is the only one left working on it now.
>> There are no updates to the community and very little knowledge sharing 
>> about this.  We need more status on this if anything.
> Submitted a 'Plan' at 
> ... suspect it is the wrong location now after all the moves and
> changes. 
> As mentioned in the document the initial ADS OSGi effort is focused on
> Structurual Componetization or to use more mundane terms - dependency
> management (aka trench warfare), but what I did not detail is that much
> of the current OSGi dev and testing work is also dealing with service
> dependency frameworks and configuration management.
> So here as some of the details ---
> Looking at what we need (and IMHO a heck of a lot of other people in the
> OSGi world will recognize they need as well) from a bottom up
> standpoint:
> -1. We need to deprecate the trunks/apache/osgi
>  0. We need a few of the common depenedencies we use throughout
> apacheds/mina wrapped as OSGi bundles.
>  1. A bundle to offer the Mina libraries, 
>  2. A bundle to offer apacheDS libraries and a jndi Backend service,
> (This bundle must offer a way to do bootstrap configuration of the
> backend server as well as offer dynamic schema loading.)
>  3. A bundle (or bundles) to offer all other shared libraries needed by
> the higher components,
>  4. A bundle to offer an apacheDS implementation of the OSGi
> Configuration Admin service. (When we have this we will draw much
> attention. Press Release time...)
>  5. Bundles offering various protocol services
> -1. trunks/apacheds/osgi
> The current OSGi work in trunks/apacheds/osgi held the seeds of what we
> have been experimenting with to date, but that said it is pretty
> stagnant and dependencies of the projects are really a mess. (I have
> previously submitted patches and/or suggestions but these have not been
> applied or acted on. )
> It retarded our efforts for the osgi parent and sub projects to be in
> this subdirectory of apacheds. (Easy to say now in hindsight.) Ideally
> OSGi support should be integral to each pom as an annotation only, not
> existing as a separate project, unless like our ConfigAdmin it actually
> implements an OSGi interface or in the case we are forced to wrap
> libraries that we don't or can't control.(more on that later) 
> So...
> I found it easier to keep my testing work in my local environment for
> now. (Would prefer to use an ADS sandbox where I would expect a welcomed
> appearance of adult from time to time for code review.)
> 0. Common libraries
> These are the libraries we need available within the OSGi runtime, but
> we do not control them. If they are not OSGi someone has to make them
> OSGi. The maven folks are looking at creating a new release of maven
> that will do this for all maven archives automatically. Unfortunately it
> is not there yet. There is always the home enough people with a need
> will get together and collectively do this. There is a 'movement' over
> at felix for doing this that seems staled. All our other efforts depend
> on this. If and when the Mina folks are ready to move and we are blocked
> here I will push it myself at felix or come up with a fast set of
> wrapper projects like we had in the trunks/apacheds/osgi projects but
> with cleaned up dependencies.
> 1. Mina
>>>From an OSGi perspective Mina should be easy to do. It is basically a
> wrapper effort. But the question has always been - one or multiple
> wrapper bundles?  A single pom will do it. Had one and even published it
> to the Mina dev at the end of August (See topic 'MINA as pure OSGi
> bundles?' in mina-dev). So what is the problem? Guess I got a greedy - I
> wanted less! I wanted no OSGi project for Mina. Right, Instead of a
> separate project, I just wanted to add the metadata to one or more of
> the Mina poms and let the OSGi plugin do its thing. After all that is
> the right thing to do if you control the code. But the problem was with
> Mina packages being spread across multiple projects, the OSGi runtime
> would take 'exception' to the fact that the various bundles were not
> offering all the classes from the advertised packages.  
> Much is still being debated at mina-dev regarding 1.1.0 and with some
> hope (from an OSGi perspective anyway) new ideas for coming up with an
> optimized java5 build for the mina 1.0.0 api. If and when that happens I
> would propose that we add an mina-integration-osgi project to that
> branch. 
> BTW - Just sent to Jira a prototype pom.xml for such a project.
> See for details.
> 2. Backend
> Current test bundle is based on the OSGi servicebinder technology, but a
> new prototype I concocted two weeks ago is based on the new spring-osgi.
> Yes that right. The Spring 2.1 release will be OSGi enabled! Just doing
> testing this week with it and should have something more concrete by
> next week. (I sure was hoping for something like spring-osgi to fall out
> the sky and help use with our bootstrap config problems - and now it
> has.)
> 4. Configuration Admin.
> Current test bundle is also based on servicebinder, after backend is
> retrode to spring-osgi will try the same here. Our implementation has
> several design features(?) that require more of a discussion which of
> course requires an interested group of parties to exchange ideas.
> Hopefully as we gain momentum this will change.
> 5. Protocols
> Have done nothing myself here, but expect to rapidly follow once
> ConfigAdmin is done. Enrique's old code from the trunks/osgi should once
> again provide valuable.
> - John

View raw message