You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2006/11/02 20:14:55 UTC
[IMPORTANT] Status of Apache Directory
Hi all,
Lately some things have been slowing down and I just want to see were we
are and who is working on what. Who is still around :)?
With the recent emergence of MINA from the Directory TLP to be its own
TLP I think it's a good time to recap on what's going on and the current
state of affairs.
Summary:
1). New Code Imports
2). Documentation and Site
3). 1.5.x Branch Roadmap
4). OSGi Plan
5). Community Growth
================
New Code Imports
================
Mitosis
-------
We just imported mitosis into the ADS 1.5.x branch. Mitosis is a
multimaster replication module that Trustin Lee wrote for ApacheDS a
while back while working with my company Solarsis Group. Solarsis
contributed the source to the ASF and all IP has been cleared.
We imported this code but we're working on better integrating it. It
now compiles and we're trying to test it to see if it still works after
the 1.0 release.
We're working with Trustin to transfer as much of the knowledge he has
to others on the project currently so others can work in it besides just
Trustin, Emmanuel, and I.
Mitosis needs lots of work. Refactoring and testing under heavy load.
So volunteers are welcome!
Triplesec
---------
An identity management solution built on top of ApacheDS. Right now
tsec has had all documentation and IP cleared for import and it's ready.
I just have not had the time to move it over and change the package names.
Not only this but I have to revamp the schema which is a mess and make
sure we use Apache Enterprise numbers instead of safehaus ones. So
there is a lot of work that needs to be done here.
WE NEED VOLUNTEERS!
==========================
Documentation and the Site
==========================
We're in really sad shape here. Almost everything is well out of date
and we need to revamp the site to include all the documentation that we
have in the ASF confluence which now has all the stuff which was at
Safehaus.
We need someone to take the lead here. Ersin? Stefan?
====================
1.5.x Branch Roadmap
====================
a) refactor
i) cleanup jndi code
ii) cleanup intercepted methods
iii) introduce new request context object
iv) introduce a session object
v) cleanup misuse of next interceptor and nexus and use the proper
bypass instructions
vi) hierarchical partitioning
b) features
i) Triggers
ii) Better sandbox (security) for stored procedures
iii) SASL
iv) DSML Service
v) Web Interface
vi) Transactions
vii) Quartz integration
Refactor
--------
We need a clear roadmap to be defined for the 1.5.x developmental
branch. I agree with Trustin that we need to seriously refactor some
nasty JNDI code out of the core to clean it up.
First I think we should refactor the code to better organize it. Then
we need to think about whether or not we're going to cleanup intercepted
methods and introduce a session and request (Context) objects instead of
each interceptor method having a bunch of arguments.
In some places we use the next interceptor or the nexus directly instead
of using the proper bypass instructions. With mitosis this will be a
problem so we need to cleanup and use this code properly.
We need to make it so several nexus' can exist and that the nexus itself
can store entries.
Features
--------
Next we need to think about features that are to be added and completed
in this branch. Some things have already started but are half complete
like the trigger implementation. We need a time table for that. We
also need a good sandbox for code executed as stored procedures.
I talked to Trustin about implementing SASL and we think we can shoot
for implementing this feature soon after some refactoring of the core.
Looks like PAM Is working on some DSML code and he would like to
integrate it into the core. PAM please start working in the sandbox
with your code right before attempting this merge.
For DSML and a web based configuration console both at start up for the
initial configs and on going configuration we can embed Jetty and have a
web console like the one that is in Tsec.
Transactions anyone? These are not transactions across multiple LDAP
operations. These are transactions that make it so we can recover
easily on abrupt shutdowns and to make all operations atomic. This is a
serious issue with triggers.
We need quartz integration and should pull it out of the mitosis code.
We need to do certain time triggered tasks and it makes sense to have it.
=========
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.
================
Community Growth
================
We're still a small community even though we just added 7-8 new
committers. Not many stuck around it seems but it may be too early to tell.
I'd like to see an effort to increase the number of active committers on
this project. Everyone should help think about how we can do this.
More people are welcome as usual.
Alex
Re: [IMPORTANT] Status of Apache Directory
Posted by Alex Karasulu <ao...@bellsouth.net>.
Jörg Henne wrote:
> Alex Karasulu schrieb:
>> We're still a small community even though we just added 7-8 new
>> committers. Not many stuck around it seems but it may be too early to
>> tell.
> Unfortunately, I guess that means me, for example. Well, I dearly hope
> that in my case it is really too early to tell, but, contrary to the
> impression one might get, <quote flick="quest for the holy grail">I'm
> not dead yet!</quote> :-) - just bogged down with other work... *sigh*
No worries Jörg this will happen to some people and this is natural. So
please don't feel like I am talking about you specifically.
I'm just saying it's happened to almost all but a couple of the new
committers ;). I'm looking at the overall trend which does not look good.
Alex
Re: [IMPORTANT] Status of Apache Directory
Posted by Jörg Henne <j....@levigo.de>.
Alex Karasulu schrieb:
> We're still a small community even though we just added 7-8 new
> committers. Not many stuck around it seems but it may be too early to
> tell.
Unfortunately, I guess that means me, for example. Well, I dearly hope
that in my case it is really too early to tell, but, contrary to the
impression one might get, <quote flick="quest for the holy grail">I'm
not dead yet!</quote> :-) - just bogged down with other work... *sigh*
Joerg Henne
Re: [IMPORTANT] Status of Apache Directory
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex Karasulu a écrit :
> Hi all,
Hi Alex,
>
> Lately some things have been slowing down and I just want to see were
> we are and who is working on what. Who is still around :)?
Well, I guess this is quite normal after a release, as everybody was
quite under pressure and need to recover a little bit :) (at least, this
was true for me)
>
> With the recent emergence of MINA from the Directory TLP to be its own
> TLP I think it's a good time to recap on what's going on and the
> current state of affairs.
>
> Summary:
>
> 1). New Code Imports
> 2). Documentation and Site
> 3). 1.5.x Branch Roadmap
> 4). OSGi Plan
> 5). Community Growth
>
> ================
> New Code Imports
> ================
>
> Mitosis
> -------
>
> We just imported mitosis into the ADS 1.5.x branch. Mitosis is a
> multimaster replication module that Trustin Lee wrote for ApacheDS a
> while back while working with my company Solarsis Group. Solarsis
> contributed the source to the ASF and all IP has been cleared.
>
> We imported this code but we're working on better integrating it. It
> now compiles and we're trying to test it to see if it still works
> after the 1.0 release.
>
> We're working with Trustin to transfer as much of the knowledge he has
> to others on the project currently so others can work in it besides
> just Trustin, Emmanuel, and I.
>
> Mitosis needs lots of work. Refactoring and testing under heavy load.
>
> So volunteers are welcome!
I volunteer, but I won't lead the effort ;)
>
> Triplesec
> ---------
>
> An identity management solution built on top of ApacheDS. Right now
> tsec has had all documentation and IP cleared for import and it's ready.
>
> I just have not had the time to move it over and change the package
> names.
>
> Not only this but I have to revamp the schema which is a mess and make
> sure we use Apache Enterprise numbers instead of safehaus ones. So
> there is a lot of work that needs to be done here.
>
> WE NEED VOLUNTEERS!
I volunteer to, but I must admit that it won't be my first priority. The
main problem with Triplesec is that it's a plain new piece of software,
and we need to understand how it works. However, I already changed all
the headers, and I think that a full code review (I mean, check for
javadoc, coding rules respect, etc is the best solution to jump into the
code)
>
> ==========================
> Documentation and the Site
> ==========================
>
> We're in really sad shape here. Almost everything is well out of date
> and we need to revamp the site to include all the documentation that
> we have in the ASF confluence which now has all the stuff which was at
> Safehaus.
>
> We need someone to take the lead here. Ersin? Stefan?
Yeah, we badly need someone to take the lead on this ! Men, the site and
doco sucks ... (ok, may be not that much, but we have bits into xml
files, bits in moin-moin, bit on safehaus, bits on cwiki, we need to
reorganize the whole stuff). At this point, a book may be a good idea,
because not only it will be a great thing to have, but also because it
will bring some structuration to our doco...
>
> ====================
> 1.5.x Branch Roadmap
> ====================
>
> a) refactor
> i) cleanup jndi code
> ii) cleanup intercepted methods
> iii) introduce new request context object
> iv) introduce a session object
> v) cleanup misuse of next interceptor and nexus and use
> the proper bypass instructions
> vi) hierarchical partitioning
I will add "inclusion of dynamic schema", using the code provided by
Norval. This is really painfull to use a plugin to add a new schema ...
The codec need to be reviewed too.
>
>
> b) features
>
> i) Triggers
> ii) Better sandbox (security) for stored procedures
> iii) SASL
> iv) DSML Service
> v) Web Interface
> vi) Transactions
> vii) Quartz integration
And LdapStudio (pam is working on it), JMX -if we don't have OSGI on the
first place -,better logging etc...
>
> Refactor
> --------
>
> We need a clear roadmap to be defined for the 1.5.x developmental
> branch. I agree with Trustin that we need to seriously refactor some
> nasty JNDI code out of the core to clean it up.
Ohhhh yeah !
>
> First I think we should refactor the code to better organize it. Then
> we need to think about whether or not we're going to cleanup
> intercepted methods and introduce a session and request (Context)
> objects instead of each interceptor method having a bunch of arguments.
>
> In some places we use the next interceptor or the nexus directly
> instead of using the proper bypass instructions. With mitosis this
> will be a problem so we need to cleanup and use this code properly.
>
> We need to make it so several nexus' can exist and that the nexus
> itself can store entries.
The first step would be to have a betyter doc. I have started a cwiki
page about interceptors, but it's far from being finished ...
>
>
> Features
> --------
>
> Next we need to think about features that are to be added and
> completed in this branch. Some things have already started but are
> half complete like the trigger implementation. We need a time table
> for that. We also need a good sandbox for code executed as stored
> procedures.
>
> I talked to Trustin about implementing SASL and we think we can shoot
> for implementing this feature soon after some refactoring of the core.
>
> Looks like PAM Is working on some DSML code and he would like to
> integrate it into the core. PAM please start working in the sandbox
> with your code right before attempting this merge.
>
> For DSML and a web based configuration console both at start up for
> the initial configs and on going configuration we can embed Jetty and
> have a web console like the one that is in Tsec.
>
> Transactions anyone? These are not transactions across multiple LDAP
> operations. These are transactions that make it so we can recover
> easily on abrupt shutdowns and to make all operations atomic. This is
> a serious issue with triggers.
>
> We need quartz integration and should pull it out of the mitosis code.
> We need to do certain time triggered tasks and it makes sense to have it.
We also need a memory partition, and a reorganization of the current
backend structure. We have a lot of gain to expect from this part. We
may need to review the way we serialize data into the backend, it's far
from being optimal.
>
> =========
> 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.
Who is leading this OSGI stuff ?
>
> ================
> Community Growth
> ================
>
> We're still a small community even though we just added 7-8 new
> committers. Not many stuck around it seems but it may be too early to
> tell.
>
> I'd like to see an effort to increase the number of active committers
> on this project. Everyone should help think about how we can do this.
>
> More people are welcome as usual.
yeah ! We will do our best to help newcommer. Any mail will be quickly
answered (yes, it will !) and as said somebody in USA (don't remember
who, gosh ... ;) : "No one will be left behind".
Emmanuel
Re: [IMPORTANT] Status of Apache Directory
Posted by Stefan Zoerner <st...@labeo.de>.
Alex Karasulu wrote:
>
> ==========================
> Documentation and the Site
> ==========================
>
> We're in really sad shape here. Almost everything is well out of date
> and we need to revamp the site to include all the documentation that we
> have in the ASF confluence which now has all the stuff which was at
> Safehaus.
>
> We need someone to take the lead here. Ersin? Stefan?
>
Currently, I am still in the overwork state due to my job alteration in
summer. I think this will change in 2-3 weeks. Furthermore I will drop
my portlet activities after a conference event with Carsten Ziegeler
next week. This decision will hopefully add some extra time for ApacheDS.
I plan to spend the time in documentation efforts -- content creation in
the first place. But after my good experience with the certification
sub-project I volunteer to take the lead here, although Ersin has
probably more experience with this (I have none). Coordination in this
place will perhaps make it easier for our new committers to contribute.
But you have to be patient, the next 2-3 weeks I won't have that much time.
Greetings from Frankfurt,
Stefan
Re: [IMPORTANT] Status of Apache Directory
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Nov 2, 2006, at 11:14 AM, Alex Karasulu wrote:
> Hi all,
>
> Lately some things have been slowing down and I just want to see
> were we are and who is working on what. Who is still around :)?
I'm still around! :D
Some day I'll have time ti tinker with the ASN1 compiler...
Regards,
Alan
Re: OSGi Initiative Status
Posted by Alex Karasulu <ao...@bellsouth.net>.
John E. Conlon wrote:
> On Fri, 2006-11-03 at 17:53 -0500, Alex Karasulu wrote:
>
>> Ok what are we moving into felix common?
> Four third party wrapping projects:
> antlr-osgi
> commons-collections-osgi
> commons-lang-osgi
> server-logger-osgi
> (The first three projects have no java sources, they only have a
> pom.xml, while the server-logger-osgi, adds only an OSGi Activator class
> for dynamic manipulation of log levels in an OSGi environment.) Few
> moving parts.
Cool thanks.
>> And will not moving our stuff
>> over to felix common not make it harder for others to commit on those
>> sources?
> There will be little reason to change these once these build and deploy
> a valid bundle to a maven repository. They will then be available to us
> as well as others that may not use ADS/Mina. The commons effort at Felix
> is only a stopgap effort with the goal to make valid OSGi bundles from
> common libraries that now are not valid OSGi bundles.
Ok understood. Sounds good thanks for the update John.
>> 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.
>> Rather than get with Richard (a person) we should be asking about how to
>> start working the commons thing on the community's dev list.
> Right
>> Also if
>> you're a main driver for doing things in there you can get commit rights
>> which should be the case.
> Ditto
>>> 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
>> You already have rights to commit to the directory project which still
>> for now includes MINA.
> Don't remember seeing an email with username/password for svn. How can I
> obtain these?
Hmmm you'll have to ask at infrastructure@apache.org. They will be able
to help you. If I remember correctly there might be a form to set your
svn password out there.
You're in the authz file so your account was created and I was able to
add you.
>> I recommend creating a private MINA branch in
>> your personal sandbox area and making the appropriate changes there then
>> presenting this idea to the MINA dev list.
>>
>> WDYT?
>>
>> This should be more proactive and they can see just what you are
>> proposing first hand by investigating your branch.
> This is what I had in mind as well.
Great.
Thanks,
Alex
Re: OSGi Initiative Status (was: Re: [IMPORTANT] Status of Apache
Directory)
Posted by "John E. Conlon" <jc...@verticon.com>.
On Fri, 2006-11-03 at 17:53 -0500, Alex Karasulu wrote:
> Ok what are we moving into felix common?
Four third party wrapping projects:
antlr-osgi
commons-collections-osgi
commons-lang-osgi
server-logger-osgi
(The first three projects have no java sources, they only have a
pom.xml, while the server-logger-osgi, adds only an OSGi Activator class
for dynamic manipulation of log levels in an OSGi environment.) Few
moving parts.
> And will not moving our stuff
> over to felix common not make it harder for others to commit on those
> sources?
There will be little reason to change these once these build and deploy
a valid bundle to a maven repository. They will then be available to us
as well as others that may not use ADS/Mina. The commons effort at Felix
is only a stopgap effort with the goal to make valid OSGi bundles from
common libraries that now are not valid OSGi bundles.
> 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.
>
> Rather than get with Richard (a person) we should be asking about how to
> start working the commons thing on the community's dev list.
Right
> Also if
> you're a main driver for doing things in there you can get commit rights
> which should be the case.
Ditto
>
> > 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
>
> You already have rights to commit to the directory project which still
> for now includes MINA.
Don't remember seeing an email with username/password for svn. How can I
obtain these?
> I recommend creating a private MINA branch in
> your personal sandbox area and making the appropriate changes there then
> presenting this idea to the MINA dev list.
>
> WDYT?
>
> This should be more proactive and they can see just what you are
> proposing first hand by investigating your branch.
This is what I had in mind as well.
John
OSGi Initiative Status (was: Re: [IMPORTANT] Status of Apache Directory)
Posted by Alex Karasulu <ao...@bellsouth.net>.
John E. Conlon wrote:
> 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.
True.
> 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,
Ok what are we moving into felix common? And will not moving our stuff
over to felix common not make it harder for others to commit on those
sources?
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.
Rather than get with Richard (a person) we should be asking about how to
start working the commons thing on the community's dev list. Also if
you're a main driver for doing things in there you can get commit rights
which should be the case.
> 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
You already have rights to commit to the directory project which still
for now includes MINA. I recommend creating a private MINA branch in
your personal sandbox area and making the appropriate changes there then
presenting this idea to the MINA dev list.
WDYT?
This should be more proactive and they can see just what you are
proposing first hand by investigating your branch.
Alex
Re: [IMPORTANT] Status of Apache Directory
Posted by Alex Karasulu <ao...@bellsouth.net>.
John E. Conlon wrote:
> 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.
True.
> 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,
Ok what are we moving into felix common? And will not moving our stuff
over to felix common not make it harder for others to commit on those
sources?
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.
Rather than get with Richard (a person) we should be asking about how to
start working the commons thing on the community's dev list. Also if
you're a main driver for doing things in there you can get commit rights
which should be the case.
> 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
You already have rights to commit to the directory project which still
for now includes MINA. I recommend creating a private MINA branch in
your personal sandbox area and making the appropriate changes there then
presenting this idea to the MINA dev list.
WDYT?
This should be more proactive and they can see just what you are
proposing first hand by investigating your branch.
Alex
Re: [IMPORTANT] Status of Apache Directory
Posted by "John E. Conlon" <jc...@verticon.com>.
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
> >
> >
> >
> >
>
Re: [IMPORTANT] Status of Apache Directory
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
>
>
>
>
Re: [IMPORTANT] Status of Apache Directory
Posted by "John E. Conlon" <jc...@verticon.com>.
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