directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: [IMPORTANT] Status of Apache Directory
Date Fri, 03 Nov 2006 20:41:11 GMT
OSGi Movement at ADS I think will be the product of both desire and
pressure.  So we just need to keep showing the benefits of OSGi and
working to impress the technology into our current projects.

In the short term we need to work with some of our sister projects:
Felix 'Commons'
We must move forward on the Felix commons idea. If no one is doing it I
would be willing to do it myself asap (next week?). Will move our
required common osgi bundles over there. If this makes sense, Alex can
you get with Richard Hall and create a place for the commons, and get me
a svn userid/pw with commit access so I can redeploy our common
dependencies to there? If necessary (from the felix community
standpoint) I can also help with other wrapping efforts besides the few
we need.

Mina
There will open a window of opportunity for us to add OSGi wrapping
subproject project to Mina as soon as Peter Royal creates a Java5
optimized Mina 1.0.0 compatible branch. Can you help facilitate the
idea? JIRA:  http//issues.apache.org/jira/browse/DIRMINA-27 

John


On Fri, 2006-11-03 at 07:57 -0500, Alex Karasulu wrote:
> 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?
> 
> Alex
> 
> 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 
> > http://docs.safehaus.org/display/APACHEDS/OSGi+and+ApacheDS
> > 
> > ... 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 http://issues.apache.org/jira/browse/DIRMINA-27 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
> > 
> > 
> > 
> > 
> 


Mime
View raw message