Think it is time to begin the process of moving OSGi into our trunk for
the 1.5.0-SNAPSHOT.

Propose that instead of adding parallel projects that wrap our existing
projects in OSGi bundles, that we instead add OSGi metadata to the jars
that are created by our existing projects.   This is easily done by
adding the org.apache.felix maven-bundle-plugin to our subproject
pom.xml files.

While Enrique and I used wrapping techniques in our initial OSGi
parallel project experimentations, working more directly on each of our
subprojects offers IMO significant advantages.

1. Fewer projects. It's basically a few lines in an existing project
versus a new project.
+ N existing projects versus N x 2 projects via the wrapper approach.
+ While it is possible to wrap multiple subprojects in uber OSGi
bundles, this still will produce N number of additional projects for us
to maintain.

2.  Direct control of OSGi metadata would offer techniques for improved
decoupling between subprojects
+ Working directly with OSGi  (Subproject) developers will have the
tools (via plugin instructions) to begin to focus on offering to users
of their jars (bundles) public exported packages as well as hiding
implementation in private packages within the module.

3.  Better modularity at deploy time.

What does everyone think?

cheers,
John

[ Post a follow-up to this message ]

Sounds really cool :-)
+2

Incidentally - I'm writing a Unit Testing Guide.

In it I'm recommending that all methods be made
public,
and if the temptation was to make them private, put
them in "Helper" classes instead that are named

ClassToBeHelpedHelper, indicating that they have a
very close relationship with ClassToBeHelped, so be
careful.

I'm anticipating objections, which is ok, it's just a
suggestion to get unit tests coupled tightly to code,
although it sounds like

> implementation in private packages within the
> module.

Might be helpful with respect to this.

Thoughts?

Thanks,
- Ole



In it
--- "John E. Conlon" <jconlon-H77XNXO9PA9Wk0Htik3J/w@public.gmane.org> wrote
:

> Think it is time to begin the process of moving OSGi
> into our trunk for
> the 1.5.0-SNAPSHOT.
>
> Propose that instead of adding parallel projects
> that wrap our existing
> projects in OSGi bundles, that we instead add OSGi
> metadata to the jars
> that are created by our existing projects.   This is
> easily done by
> adding the org.apache.felix maven-bundle-plugin to
> our subproject
> pom.xml files.
>
> While Enrique and I used wrapping techniques in our
> initial OSGi
> parallel project experimentations, working more
> directly on each of our
> subprojects offers IMO significant advantages.
>
> 1. Fewer projects. It's basically a few lines in an
> existing project
> versus a new project.
>     + N existing projects versus N x 2 projects via
> the wrapper approach.
>     + While it is possible to wrap multiple
> subprojects in uber OSGi
> bundles, this still will produce N number of
> additional projects for us
> to maintain.
>
> 2.  Direct control of OSGi metadata would offer
> techniques for improved
> decoupling between subprojects
>     + Working directly with OSGi  (Subproject)
> developers will have the
> tools (via plugin instructions) to begin to focus on
> offering to users
> of their jars (bundles) public exported packages as
> well as hiding
> implementation in private packages within the
> module.
>
> 3.  Better modularity at deploy time.
>
> What does everyone think?
>
> cheers,
> John
>
>
>
>
>
>
>




 ________________________________________
____________________________________
________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/ar...edsearch_v2.php

[ Post a follow-up to this message ]

John,

Doing this means committing to OSGi and I'm not going to be too
comfortable with doing this until I see:

(1) some good "in situ" integration testing framework that allows us to
easily test services within the target container as part of the maven
build process,
(2) good test coverage, testing the integrated system of ApacheDS
services running inside an OSGi container (you need #1 for this)
(3) solid documentation in confluence for this OSGi based architecture
for ApacheDS
(4) Felix graduating with a 1.0 release that has full support for R4
(and has things like it's plugin deployed to Ibiblio so we don't have
Maven hick ups with SNAPSHOT plugin artifacts),
(5) greater team awareness of this OSGi based architecture,
(6) more consideration for OSGi alternatives like xbean,
(7) and time for us all to be involved to make sure something does not
go wrong during this move to OSGi.

#1 can be accomplished by the time #4 occurs through the Felix
community.  #2 and #3 are up to you and Enrique.  #4 will probably
happen soon.  IMO the big problems are #5, #6 and #7.  You posted some
very good emails out there on the status of your effort but we need
something more to make this catch on for #5.  In an ideal world we would
all be able to experiment with different containers (for #6) but we just
don't have the time which leads again to #7.

To tell you the truth we have big concerns that overshadow the container
effort right now.  First on that list is multi master replication so we
can make the directory and all that rests upon it fault tolerant.

That does not mean I am not interested in OSGi or getting this stuff
working and integrated into the main trunk.  I'm sure we're going to see
several benefits from using a container again.

Alex

John E. Conlon wrote:
> Think it is time to begin the process of moving OSGi into our trunk for
> the 1.5.0-SNAPSHOT.
> Propose that instead of adding parallel projects that wrap our existing
> projects in OSGi bundles, that we instead add OSGi metadata to the jars
> that are created by our existing projects.   This is easily done by
> adding the org.apache.felix maven-bundle-plugin to our subproject
> pom.xml files.
> While Enrique and I used wrapping techniques in our initial OSGi
> parallel project experimentations, working more directly on each of our
> subprojects offers IMO significant advantages.
>
> 1. Fewer projects. It's basically a few lines in an existing project
> versus a new project.
>    + N existing projects versus N x 2 projects via the wrapper approach.
>    + While it is possible to wrap multiple subprojects in uber OSGi
> bundles, this still will produce N number of additional projects for us
> to maintain.
> 2.  Direct control of OSGi metadata would offer techniques for improved
> decoupling between subprojects
>    + Working directly with OSGi  (Subproject) developers will have the
> tools (via plugin instructions) to begin to focus on offering to users
> of their jars (bundles) public exported packages as well as hiding
> implementation in private packages within the module.
>
> 3.  Better modularity at deploy time.
>
> What does everyone think?
>
> cheers,
> John
>
>
>
>
>
>
>

[ Post a follow-up to this message ]

John,

I'd be interested in helping with the "Integration
Testing Framework" part (I'm actually interested in
helping with a lot more, but I only have half a brain,
and that only works part of the time so...)

Anyways, I think it would make a nice little companion
top in the "Testing Guide" that I'm writing anyways.

Cheers,
- Ole


--- Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:

> John,
>
> Doing this means committing to OSGi and I'm not
> going to be too
> comfortable with doing this until I see:
>
> (1) some good "in situ" integration testing
> framework that allows us to
> easily test services within the target container as
> part of the maven
> build process,
> (2) good test coverage, testing the integrated
> system of ApacheDS
> services running inside an OSGi container (you need
> #1 for this)
> (3) solid documentation in confluence for this OSGi
> based architecture
> for ApacheDS
> (4) Felix graduating with a 1.0 release that has
> full support for R4
> (and has things like it's plugin deployed to Ibiblio
> so we don't have
> Maven hick ups with SNAPSHOT plugin artifacts),
> (5) greater team awareness of this OSGi based
> architecture,
> (6) more consideration for OSGi alternatives like
> xbean,
> (7) and time for us all to be involved to make sure
> something does not
> go wrong during this move to OSGi.
>
> #1 can be accomplished by the time #4 occurs through
> the Felix
> community.  #2 and #3 are up to you and Enrique.  #4
> will probably
> happen soon.  IMO the big problems are #5, #6 and
> #7.  You posted some
> very good emails out there on the status of your
> effort but we need
> something more to make this catch on for #5.  In an
> ideal world we would
> all be able to experiment with different containers
> (for #6) but we just
> don't have the time which leads again to #7.
>
> To tell you the truth we have big concerns that
> overshadow the container
> effort right now.  First on that list is multi
> master replication so we
> can make the directory and all that rests upon it
> fault tolerant.
>
> That does not mean I am not interested in OSGi or
> getting this stuff
> working and integrated into the main trunk.  I'm
> sure we're going to see
> several benefits from using a container again.
>
> Alex
>
> John E. Conlon wrote: 
> OSGi into our trunk for 
> that wrap our existing 
> metadata to the jars 
> is easily done by 
> our subproject 
> our initial OSGi 
> directly on each of our 
> an existing project 
> the wrapper approach. 
> subprojects in uber OSGi 
> additional projects for us 
> techniques for improved 
> developers will have the 
> on offering to users 
> as well as hiding 
> module. 
> 
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;internet:akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org
> title:Member, V.P.
> tel;work904) 791-2766
> tel;fax904) 808-4789
> tel;home904) 808-4789
> tel;cell904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> 	MSN: aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org=0D=0A=
> 	Yahoo!: alexkarasulu=0D=0A=
> 	IRC: aok=0D=0A=
> 	PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
>
> x-mozilla-html:FALSE
> url:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
>
>




 ________________________________________
____________________________________
________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it no
w.

[ Post a follow-up to this message ]

Hey Guys,

It looks like James (Apache Mail Server) has done a
lot of research on XBean and OSGi already.

It sounds like they are favoring OSGi over XBean due
in part to it being standardized through JCP.  It also
sounds like there is an XBean facade for OSGi.

Here's a link to the James thread, starting where the
discussion gets goooood.

http://mail-archives.apache.org/mod...br />
e.org%3e

Incidentally - Since they seems to be doing a lot of
work around this already, I think it would make sense
to combine our efforts with respect to Alex's list
below.

Cheers,
- Ole


--- Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:

> John,
>
> Doing this means committing to OSGi and I'm not
> going to be too
> comfortable with doing this until I see:
>
> (1) some good "in situ" integration testing
> framework that allows us to
> easily test services within the target container as
> part of the maven
> build process,
> (2) good test coverage, testing the integrated
> system of ApacheDS
> services running inside an OSGi container (you need
> #1 for this)
> (3) solid documentation in confluence for this OSGi
> based architecture
> for ApacheDS
> (4) Felix graduating with a 1.0 release that has
> full support for R4
> (and has things like it's plugin deployed to Ibiblio
> so we don't have
> Maven hick ups with SNAPSHOT plugin artifacts),
> (5) greater team awareness of this OSGi based
> architecture,
> (6) more consideration for OSGi alternatives like
> xbean,
> (7) and time for us all to be involved to make sure
> something does not
> go wrong during this move to OSGi.
>
> #1 can be accomplished by the time #4 occurs through
> the Felix
> community.  #2 and #3 are up to you and Enrique.  #4
> will probably
> happen soon.  IMO the big problems are #5, #6 and
> #7.  You posted some
> very good emails out there on the status of your
> effort but we need
> something more to make this catch on for #5.  In an
> ideal world we would
> all be able to experiment with different containers
> (for #6) but we just
> don't have the time which leads again to #7.
>
> To tell you the truth we have big concerns that
> overshadow the container
> effort right now.  First on that list is multi
> master replication so we
> can make the directory and all that rests upon it
> fault tolerant.
>
> That does not mean I am not interested in OSGi or
> getting this stuff
> working and integrated into the main trunk.  I'm
> sure we're going to see
> several benefits from using a container again.
>
> Alex
>
> John E. Conlon wrote: 
> OSGi into our trunk for 
> that wrap our existing 
> metadata to the jars 
> is easily done by 
> our subproject 
> our initial OSGi 
> directly on each of our 
> an existing project 
> the wrapper approach. 
> subprojects in uber OSGi 
> additional projects for us 
> techniques for improved 
> developers will have the 
> on offering to users 
> as well as hiding 
> module. 
> 
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;internet:akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org
> title:Member, V.P.
> tel;work904) 791-2766
> tel;fax904) 808-4789
> tel;home904) 808-4789
> tel;cell904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> 	MSN: aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org=0D=0A=
> 	Yahoo!: alexkarasulu=0D=0A=
> 	IRC: aok=0D=0A=
> 	PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
>
> x-mozilla-html:FALSE
> url:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
>
>




 ________________________________________
____________________________________
________
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com...mail_tools.html

[ Post a follow-up to this message ]

Sorry - The link below was a little further back in
the thread:

Here's the one where the OSGi discussion starts,
although the previous messages on the thread are a
good backdrop.

http://mail-archives.apache.org/mod...ic.gmane.org%3e


--- Ole Ersoy <ole_ersoy-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:

> Hey Guys,
>
> It looks like James (Apache Mail Server) has done a
> lot of research on XBean and OSGi already.
>
> It sounds like they are favoring OSGi over XBean due
> in part to it being standardized through JCP.  It
> also
> sounds like there is an XBean facade for OSGi.
>
> Here's a link to the James thread, starting where
> the
> discussion gets goooood.
>
>
http://mail-archives.apache.org/mod...ic.gmane.org%3e
>
> Incidentally - Since they seems to be doing a lot of
> work around this already, I think it would make
> sense
> to combine our efforts with respect to Alex's list
> below.
>
> Cheers,
> - Ole
>
>
> --- Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrot
e:
> 
> as 
> need 
> OSGi 
> Ibiblio 
> sure 
> through 
> #4 
> an 
> containers 
> OSGi 
> This 
> to 
> via 
> focus 
>
>
>
>
>
 ________________________________________
 ________________________________________
____
> Expecting? Get great news right away with email
> Auto-Check.
> Try the Yahoo! Mail Beta.
>
http://advision.webevents.yahoo.com...mail_tools.html
>
>




 ________________________________________
____________________________________
________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

[ Post a follow-up to this message ]

Hi Alex,

Thanks for the comments.  See inline for responses.

Alex Karasulu wrote:
> Doing this means committing to OSGi and I'm not going to be too
> comfortable with doing this until I see:
We can look at this two ways.  From one perspective we would not be
committing 'fully' to OSGi, as the decorated metadata would not affect
the behavior of the jars as they operate today.

One of the big issues for the OSGi community today is to convince
library providers to add a few lines of metadata to their jars artifacts
so they could also be used in OSGi projects.   So from this perspective
I guess I am trying to convince us to 'at least' to make our jars OSGi
friendly.

Let me respond to your to your other points from the second perspective :-)
>
> (1) some good "in situ" integration testing framework that allows us
> to easily test services within the target container as part of the
> maven build process,
Your right we need "in container" integration testing once we fully
commit to OSGi.

The Spring-OSGi effort is offering just such a testing environment.  I
am told knopflerfish also has one but have not looked into it. I have
used the Spring-OSGi testing on several occasions including testing some
of the OSGi ApacheDS bundling efforts in the sandbox.   Within the
Spring-OSGi facilities exist for testing Equinox (Eclipse's standalone
runtime), Knopflerfish and of course Felix.

Caveat is that Spring-OSGi is still in early development and the API's
are changing.  Nevertheless the testing side has been pretty stable and
allowed the kind of testing we needed.

For a simple example see my sandbox for
osgi-services/logging-service-integration-test. This tests the
neighboring logging-service project which creates a bundle which offers
slf4j/commons/LogService api adapters on the NLOG4 bindings.
Implementation and testing was eventually noticed Ceki, who asked me to
do something similar for slf4j.  This is now committed in the
1.3.0-SNAPSHOT of the slf4j project.

There is also a simple mina integration testing project in my sandbox.
It uses a chat server as a server within the OSGi container.


> (2) good test coverage, testing the integrated system of ApacheDS
> services running inside an OSGi container (you need #1 for this)
Right.  The real challenge I am faced with is to provide a Spring-OSGi
integration test for the Configuration Admin service implementation that
I committed a two weeks ago.  This will require a full stack of ApacheDS
bundles running within the various OSGi containers.  This will also
expose an LDAP service that will require test cases.

Must confess I am still not fully up to speed on the new schema
functionality to fix my broken apache-core-osgi project which I will
need for such an integration test. (Next week maybe?)
> (3) solid documentation in confluence for this OSGi based architecture
> for ApacheDS
Top down documentation without buyin by developers most often times is
ignored as it is either too abstract or if not, grows stale fast.
Especially if it is done by a single person that doesn't fully
understand the foundations of what he is documenting. (that would be me.)

What I posted at http://docs.safehaus.org/display/AP...Gi+and+ApacheDS
is still  valid as a top down viewpoint for what we are doing with OSGi
and ApacheDS today and what I am proposing with this email.

(PS - Will move it to confluence if it is not there already.)

In that document written 10 months ago I said:
"Structurual Componetization can also be called '*/Package Depenency
Management/*'.   Structurual Componentization is the initial focus of
the OSGi work effort.  It will consist of annotating ApacheDS software
artifacts with OSGi specific metadata."

This architectural document really needs more fleshing out than I  have
given it to date, but to do this I am going to need help, and the help I
need must come from the bottom up.  To continue to document the reality
based top down I need the bottom up 'trenches' view of the ApacheDS
effort.  We need to start working on the documentation at the package
and subproject basis in order to begin thinking about - '*/Package
Depenency Management/*'.

Three step loop here:
1. Document packages
2. Annotate jars ( plugin produced metadata  documents dependencies.)
3. Analyze dependencies (Refactor to improve coupling?)


As it is now the OSGi effort at ApacheDS is not sustainable as I am
doing too much outside of the group.   With my proposal I am trying to
get our community enthused enough to assist with this bottom effort.

> (4) Felix graduating with a 1.0 release that has full support for R4
> (and has things like it's plugin deployed to Ibiblio so we don't have
> Maven hick ups with SNAPSHOT plugin artifacts),
The  only plugin we need at first would be org.apache.felix
maven-bundle-plugin and it is available from one of our current default
repos:

<url>http://people.apache.org/repo/m2-snapshot-repository</url>

> (5) greater team awareness of this OSGi based architecture,
Right - thats the purpose of my proposal.
> (6) more consideration for OSGi alternatives like xbean,
> (7) and time for us all to be involved to make sure something does not
> go wrong during this move to OSGi.
Agree to #7 - ditto comment for #5.

cheers,
John

[ Post a follow-up to this message ]

John E. Conlon a écrit :

> Hi Alex,
>
> Thanks for the comments.  See inline for responses.
>
> Alex Karasulu wrote:
> 
>
> We can look at this two ways.  From one perspective we would not be
> committing 'fully' to OSGi, as the decorated metadata would not affect
> the behavior of the jars as they operate today.
> One of the big issues for the OSGi community today is to convince
> library providers to add a few lines of metadata to their jars
> artifacts so they could also be used in OSGi projects.   So from this
> perspective I guess I am trying to convince us to 'at least' to make
> our jars OSGi friendly.
> ...

Hi John, Alex,


First of all, I have to say that OSGi effort is valuable, and we have to
thank you, John, for you dedication and continuous effort regarding it
during those last months.

I want to address some of Alex concerns, and also give you my opinion on
the next few steps, and months. During last Apache Conference, we have
announced the first release of Apache Directory Server (1.0) and Mina
has become a TLP, separated from Directory. We also included three
sub-projects into Apache DS :
- triplesec,
- mitosis,
- ldap studio
This was a lot of work, and a lot of little things to manage (and you
know that it takes more time to manage many little things that one big
thing).
We are currently preparing a 1.0.1 release of ADS (a bug fix), quickly
followed by a 1.5.0 release, with a new Schema Management feature (plus
Java 5 support). We also have to make Mitosis stable for may (or even
better, before may !). The site has been totally redesigned - thanks to
Ersin, pam and many contributors-, and the documentation has been
improved - thanks to Stefan and Christine -. Again, this was a lot of work.

As Alex stated, I think this time for dust to settle a little bit. We
have a damn loaded roadmap since ApacheCon EU (may 1st), and I'm not
sure we may dedicate enough attention to OSGification of ADS before this
date.

What I would suggest is that we should put this OSGification on the
roadmap starting on may, 4th, when we will be able to back it. This is
really true that if you don't get committers attention, then it will be
hard time (many complaints to be expected ...).

I'm sorry to admit that I didn't had a minute to follow up your work,
and I didn't had time to read anything about OSGi during last year. My
bad... I really want to jump into it, as I think it will help us on many
aspect.

So, can't we wait 3 more months before we jump into OSGi for ADS? If you
feel being ready, and that we should at least fulfill some first steps
that won't harm the project, then I will be pleased to follow your
instructions (like adding meta-info into the jars), but you will have to
be very explicit about what we must do, because we will be like babies
doing our first steps : keep the way really clear of any bump and traps 

I don't want to slow you down, I just want to express my concern to be
unable to dedicate enough time for this task in the next few months. And
I guess this is also a concern for many others ADS committers...

It's just that, well, I feel like having run a marathon, and having to
run another one right now...

Hopefully, I'll be off for two weeks, so I will be in better shape when
I'll be back ;)

Emmanuel

[ Post a follow-up to this message ]

Hi Ole,

I went to the XBean site and could not find any documentation.  Is there
an article or something you could point me reference so I can take a look?

cheers,
John

Ole Ersoy wrote:
> Sorry - The link below was a little further back in
> the thread:
>
> Here's the one where the OSGi discussion starts,
> although the previous messages on the thread are a
> good backdrop.
>
> http://mail-archives.apache.org/mod...ic.gmane.org%3e
>
>
> --- Ole Ersoy <ole_ersoy-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> 
> http://mail-archives.apache.org/mod... />
ane.org%3e
> 
>  ________________________________________
__________________________________
__________
> 
> http://advision.webevents.yahoo.com...mail_tools.html
> 
>
>
>
>
>  ________________________________________
__________________________________
__________
> Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
>
>
>

[ Post a follow-up to this message ]

Never mind I found it.

thanks,
John

John E. Conlon wrote:
> Hi Ole,
>
> I went to the XBean site and could not find any documentation.  Is
> there an article or something you could point me reference so I can
> take a look?
>
> cheers,
> John
>
> Ole Ersoy wrote: 
>
>
>

[ Post a follow-up to this message ]