|
Home > Archive > Apache Directory Project > February 2007 > [OSGi] Implementing OSGi for 1.5
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[OSGi] Implementing OSGi for 1.5
|
|
| John E. Conlon 2007-02-09, 7:11 pm |
| 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
| |
| Ole Ersoy 2007-02-10, 1:11 am |
| 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
| |
| Alex Karasulu 2007-02-10, 1:11 am |
| 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
>
>
>
>
>
>
>
| |
| Ole Ersoy 2007-02-10, 1:11 am |
| 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;work 904) 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 now.
| |
| Ole Ersoy 2007-02-10, 1:11 pm |
| 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> 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
| |
| Ole Ersoy 2007-02-10, 1:11 pm |
| 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> wrote:
>
> 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
| |
| John E. Conlon 2007-02-10, 1:11 pm |
| 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
| |
| Emmanuel Lecharny 2007-02-10, 1:11 pm |
| 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
| |
|
|
| John E. Conlon 2007-02-10, 1:11 pm |
| 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:
>
>
>
| |
| David Jencks 2007-02-10, 1:11 pm |
| IMO if including the osgi metadata in the jars won't break anything =20
else we should put it in right away. It doesn't need to work =20
completely or even partially. I think that one of the benefits of =20
the osgi effort even for non-osgi uses is that it encourages cleaner =20
division of responsibility between jars and again IMO anything that =20
makes problems in this area visible even if they don't get fixed =20
immediately is a good thing.
I would not support forcing anyone to change their coding style for =20
public/private method access, use of getter/setters etc in order to =20
use OSGI. I do think that generating classloading metadata is a good =20=
thing.
thanks
david jencks
On Feb 10, 2007, at 9:47 AM, Emmanuel Lecharny wrote:
> John E. Conlon a =E9crit :
>
[vbcol=seagreen]
[vbcol=seagreen]
>
> Hi John, Alex,
>
>
> First of all, I have to say that OSGi effort is valuable, and we =20
> have to thank you, John, for you dedication and continuous effort =20
> regarding it during those last months.
>
> I want to address some of Alex concerns, and also give you my =20
> opinion on the next few steps, and months. During last Apache =20
> Conference, we have announced the first release of Apache Directory =20=
> Server (1.0) and Mina has become a TLP, separated from Directory. =20
> 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 =20
> you know that it takes more time to manage many little things that =20
> one big thing).
> We are currently preparing a 1.0.1 release of ADS (a bug fix), =20
> quickly followed by a 1.5.0 release, with a new Schema Management =20
> feature (plus Java 5 support). We also have to make Mitosis stable =20
> for may (or even better, before may !). The site has been totally =20
> redesigned - thanks to Ersin, pam and many contributors-, and the =20
> documentation has been improved - thanks to Stefan and Christine -. =20=
> Again, this was a lot of work.
>
> As Alex stated, I think this time for dust to settle a little bit. =20
> We have a damn loaded roadmap since ApacheCon EU (may 1st), and I'm =20=
> not sure we may dedicate enough attention to OSGification of ADS =20
> before this date.
>
> What I would suggest is that we should put this OSGification on the =20=
> roadmap starting on may, 4th, when we will be able to back it. This =20=
> is really true that if you don't get committers attention, then it =20
> 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 =20
> work, and I didn't had time to read anything about OSGi during last =20=
> year. My bad... I really want to jump into it, as I think it will =20
> help us on many aspect.
>
> So, can't we wait 3 more months before we jump into OSGi for ADS? =20
> If you feel being ready, and that we should at least fulfill some =20
> first steps that won't harm the project, then I will be pleased to =20
> follow your instructions (like adding meta-info into the jars), but =20=
> you will have to be very explicit about what we must do, because we =20=
> will be like babies doing our first steps : keep the way really =20
> clear of any bump and traps
>
> I don't want to slow you down, I just want to express my concern to =20=
> be unable to dedicate enough time for this task in the next few =20
> months. And I guess this is also a concern for many others ADS =20
> committers...
>
> It's just that, well, I feel like having run a marathon, and having =20=
> to run another one right now...
>
> Hopefully, I'll be off for two weeks, so I will be in better shape =20
> when I'll be back ;)
>
> Emmanuel
| |
| Stefano Bagnara 2007-02-10, 1:11 pm |
| Ole Ersoy ha scritto:
> Hey Guys,
>
> It looks like James (Apache Mail Server) has done a
> lot of research on XBean and OSGi already.
Hi Ole, I'm a James PMC member,
Well, we did not really much research. One fine day Alan Cabrera
suggested us to move to maven2+xbean: someone liked the idea, someone
didn't.
At that time XBean was at an early stage and spring 2 was not out yet (I
say this because I'm under the impression that XBean changed enough with
the introduction of spring 2, but I may be wrong).
So we never really evaluated XBean seriously. The same apply to OSGi.
The only real/concrete step we did has been some experimentation with
Spring2.
> 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.
Maybe this is "old news": now I think the key is that XBean runs on
spring2 and there is a promising spring-osgi support.
It is indeed true that many JAMES PMC committers expressed favourable
opinions against OSGi (nothing more than this).
> 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.
I just read this article and I liked it very much:
http://www.eclipsezone.com/articles...ns-vs-services/
This increased my believing that spring-osgi is probably the way to go.
I would like to understand what XBean provides on top of this or what
the are really doing but I found it difficult to understand what is the
XBean roadmap from their website/jira.
Unfortunately we didn't do any work. Btw I'm really interested in this
and in my TODO list I have "Understand XBean<->SpringOSGi relationship".
Stefano
| |
| Ole Ersoy 2007-02-10, 1:11 pm |
| Hi Stefano,
Thanks for all the elaboration.
Hopefully we'll have a common approach to both James
and ApacheDS in the end so that we can share
documentation and maintenance efforts across both
servers.
Incidentally I have a couple of questions for you
regarding James installers, but let me start a new
thread for that. I'll post one with "[COLLABORATION]
James" in the subject
Cheers,
- Ole
--- Stefano Bagnara <apache-HTWyZx301W8@public.gmane.org> wrote:
> Ole Ersoy ha scritto:
> a
>
> Hi Ole, I'm a James PMC member,
>
> Well, we did not really much research. One fine day
> Alan Cabrera
> suggested us to move to maven2+xbean: someone liked
> the idea, someone
> didn't.
>
> At that time XBean was at an early stage and spring
> 2 was not out yet (I
> say this because I'm under the impression that XBean
> changed enough with
> the introduction of spring 2, but I may be wrong).
>
> So we never really evaluated XBean seriously. The
> same apply to OSGi.
> The only real/concrete step we did has been some
> experimentation with
> Spring2.
>
> due
> also
>
> Maybe this is "old news": now I think the key is
> that XBean runs on
> spring2 and there is a promising spring-osgi
> support.
>
> It is indeed true that many JAMES PMC committers
> expressed favourable
> opinions against OSGi (nothing more than this).
>
> the
>
http://mail-archives.apache.org/mod...ic.gmane.org%3e
> of
> sense
>
> I just read this article and I liked it very much:
>
http://www.eclipsezone.com/articles...ns-vs-services/
>
> This increased my believing that spring-osgi is
> probably the way to go.
>
> I would like to understand what XBean provides on
> top of this or what
> the are really doing but I found it difficult to
> understand what is the
> XBean roadmap from their website/jira.
>
> Unfortunately we didn't do any work. Btw I'm really
> interested in this
> and in my TODO list I have "Understand
> XBean<->SpringOSGi relationship".
>
> Stefano
>
>
________________________________________
________________________________________
____
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/ar...edsearch_v2.php
| |
| John E. Conlon 2007-02-10, 7:11 pm |
| David Jencks wrote:
> IMO if including the osgi metadata in the jars won't break anything
> else we should put it in right away.
That is the idea. Just an accommodation to OSGi metadata right now.
> It doesn't need to work completely or even partially. I think that
> one of the benefits of the osgi effort even for non-osgi uses is that
> it encourages cleaner division of responsibility between jars and
> again IMO anything that makes problems in this area visible even if
> they don't get fixed immediately is a good thing.
Right. And more importantly the meta data generated by the plugin will
increase our visibility down to the package level as well. This by
itself is a side benefit which can then be used to decrease decoupling
down to packages. The metadata can then be tuned to specify which
packages are exported for public consumption and which are private.
When loaded in an OSGi runtime this decoupling to the package level is
enforced by the metadata driven OSGi classloader matrix. This is what
give OSGi applications the uptime longevity - they can be updated on the
fly.
>
> I would not support forcing anyone to change their coding style for
> public/private method access, use of getter/setters etc in order to
> use OSGI.
The same jars and packages still work as usual. Coding styles are all
the same.
I expect as people see the advantages of a cleaner division of
responsibility that OSGi brings not only at the module (jar) level but
at the package level as well we can expect to see movement from just an
OSGi accommodation to a full commitment.
But they have to see the initial benefits first.
> I do think that generating classloading metadata is a good thing.
thanks for your comments,
John
| |
| John E. Conlon 2007-02-10, 7:11 pm |
| Hi Emmanuel ,
Emmanuel Lecharny wrote:
> John E. Conlon a écrit :
>
>
> 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
Yes a few baby steps.
1. The first should be painless. If permitted I would begin by adding
the plugin to our pom.xml files (going one by one) to generate the jars
with the metadata.
2. The second step I think is something that everyone will (should)
applaud. As a matter of fact it was a subject of a recent thread.
Want to collaborate with someone ( Ole would you be interested in
working with me on this??) on an effort to start documenting all our
packages in all our projects with package-info.java files. This is the
bottom up documentation effort that I was referring to when I responded
to Alex. With this we should gain greater insight into the workings of
ADS down to the packages. As this happens I can begin to tune the
metadata to approaprately take advantage of what the module offers to
and requires of other packages. (Again this wont affect jar users, but
it will increase the decoupling of the osgi bundles.)
>
> 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...
You can ignore the OSGi side of the house. But you might be asked some
questions from time to time though, regarding the functionality of
packages (this in order to support the package doco effort).
warm regards,
John
| |
| Alex Karasulu 2007-02-11, 1:11 pm |
| John E. Conlon wrote:
> Hi Alex,
>
> Thanks for the comments. See inline for responses.
Truly thanks for your effort to push OSGi along. I really want to go
this route but I want all our bases covered.
Having read your response and Emmanuel's, I think I would like to wait
until we have a *non*-snapshot release of the OSGi plugin in the Maven
repository to use before tackling this in May or better yet June. I
don't want the build to depend on SNAPSHOT plug-ins because I would not
allow a production release so long as we did.
We can re-evaluate this and prep the team by then so we can all
participate in this OSGi aim together. It would be nice to have you
involved with the guts of ApacheDS as well as being on the periphery
with the OSGi effort and likewise I'd like to see the rest of the team
more involved with the OSGi effort. I'd like to also see if you can get
OSGi to give us certain things like JMX for free so we can better
control and instrument the server.
I want to know what our benefits are going to be and who is going to be
involved with making sure we get those benefits. Also what's the deal
with Spring-OSGi? Is there some advantage to be gained there? Do we get
the best of both worlds?
Let's get your documentation into the Apache confluence under the 1.5
confluence's developer guide area and more people on this team looking
at it and commenting on it.
This sound good?
Thanks,
Alex
> 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.
>
> Let me respond to your to your other points from the second perspective :-)
> 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.
>
>
> 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?)
> 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.
> 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>
>
> Right - thats the purpose of my proposal.
> Agree to #7 - ditto comment for #5.
>
> cheers,
> John
>
>
>
>
>
| |
| John E. Conlon 2007-02-13, 1:11 am |
| Alex Karasulu wrote:
> John E. Conlon wrote:
>
> Truly thanks for your effort to push OSGi along. I really want to go
> this route but I want all our bases covered.
>
> Having read your response and Emmanuel's, I think I would like to wait
> until we have a *non*-snapshot release of the OSGi plugin in the Maven
> repository to use before tackling this in May or better yet June. I
> don't want the build to depend on SNAPSHOT plug-ins because I would
> not allow a production release so long as we did.
>
> We can re-evaluate this and prep the team by then so we can all
> participate in this OSGi aim together. It would be nice to have you
> involved with the guts of ApacheDS as well as being on the periphery
> with the OSGi effort and likewise I'd like to see the rest of the team
> more involved with the OSGi effort. I'd like to also see if you can
> get OSGi to give us certain things like JMX for free so we can better
> control and instrument the server.
Although I have seen much activities on JMX done at Felix, I have not
used any JMX with the server. On the other hand we have a simple
command line interface that we use for searching and one for loading
ldif directly into the backend. (Without an LDAP server.)
>
> I want to know what our benefits are going to be and who is going to
> be involved with making sure we get those benefits. Also what's the
> deal with Spring-OSGi? Is there some advantage to be gained there? Do
> we get the best of both worlds?
That's the goal of the Spring-OSGi - An IOC within the module (aka jar)
that also manages registered service dependencies and service
publications between the modules (bundles).
Here is the home site:
http://www.springframework.org/osgi
In the sandbox work, the core server module utilizes a similar
server.xml to the familiar one, but with a few new Spring-OSGi namespace
enhancements.
The core server bundle's primary purpose is to offer to all other
bundles an InitialContextServiceFactory service. (A seperate bundle
offers the LDAP service.) It is still spring and pojo mostly though.
Within the project for testing purposes OSGi can effectively be ignored,
on just uses plan old JUnit or the Spring context extensions. As
mentioned before 'in container testing' is done in an integration suite
project that parallels the first. (Bundle/jars have to be built first to
test them.)
Here is what our ApacheDS Spring-OSGi service publication looks like:
<!-- Register the InitialContextFactoryImpl bean as an OSGi service -->
<osgi:service id="initialContextFactory" ref="initialContextFactoryService"
interface="javax.naming.spi.InitialContextFactory" />
<bean name="initialContextFactoryService"
class="org.apache.directory.osgi.backend.InitialContextFactoryImpl"
destroy-method="destroy"
init-method="init">
<constructor-arg ref="environment"/>
<constructor-arg ref="configuration"/>
</bean>
Benefit that is offered via OSGi is that it makes it easy to move in
either a embedded server or a JNDi reference via properties to a remote
one. (At run time without shutting down the JVM.) Could have a
combination of multiple servers running in the same VM or mixes of local
and remote servers.
>
> Let's get your documentation into the Apache confluence under the 1.5
> confluence's developer guide area and more people on this team looking
> at it and commenting on it.
>
Will do.
> This sound good?
>
No problems on resetting our priorities out to June.
John
| |
| Alex Karasulu 2007-02-13, 1:11 am |
| John E. Conlon wrote:
> Alex Karasulu wrote:
> Although I have seen much activities on JMX done at Felix, I have not
> used any JMX with the server. On the other hand we have a simple
> command line interface that we use for searching and one for loading
> ldif directly into the backend. (Without an LDAP server.)
Can you elaborate on the we? Is this your company?
> That's the goal of the Spring-OSGi - An IOC within the module (aka jar)
> that also manages registered service dependencies and service
> publications between the modules (bundles). Here is the home site:
> http://www.springframework.org/osgi
>
> In the sandbox work, the core server module utilizes a similar
> server.xml to the familiar one, but with a few new Spring-OSGi namespace
> enhancements.
>
> The core server bundle's primary purpose is to offer to all other
> bundles an InitialContextServiceFactory service. (A seperate bundle
> offers the LDAP service.) It is still spring and pojo mostly though.
> Within the project for testing purposes OSGi can effectively be ignored,
> on just uses plan old JUnit or the Spring context extensions. As
> mentioned before 'in container testing' is done in an integration suite
> project that parallels the first. (Bundle/jars have to be built first to
> test them.)
Do you already have these tests based on Spring-OSGi in place already to
test out the behavior of the bundles?
> Here is what our ApacheDS Spring-OSGi service publication looks like:
> <!-- Register the InitialContextFactoryImpl bean as an OSGi service -->
> <osgi:service id="initialContextFactory" ref="initialContextFactoryService"
> interface="javax.naming.spi.InitialContextFactory" />
>
> <bean name="initialContextFactoryService"
>
> class="org.apache.directory.osgi.backend.InitialContextFactoryImpl"
> destroy-method="destroy"
> init-method="init">
> <constructor-arg ref="environment"/>
> <constructor-arg ref="configuration"/>
> </bean>
>
> Benefit that is offered via OSGi is that it makes it easy to move in
> either a embedded server or a JNDi reference via properties to a remote
> one. (At run time without shutting down the JVM.) Could have a
> combination of multiple servers running in the same VM or mixes of local
> and remote servers.
Yeah that's cool. I like that.
> Will do.
> No problems on resetting our priorities out to June.
Thanks for understanding.
Alex
| |
| John E. Conlon 2007-02-13, 7:11 am |
| Alex Karasulu wrote:
> John E. Conlon wrote:
>
> Can you elaborate on the we? Is this your company?
No its we, Apache DS.
There is a sandbox project called apache-core-felix-tui that offers a
felix text user interface for simple searching and loading ldif into a
jndi backend.
Another thought - more radical though (its late) is to run our bundles
in the same OSGi environment (Felix or Eclipse) with LDAPStudio. LDAP
Studio is after all an Eclipse RCP - "Composed of several Eclipse (OSGi)
plugins, LDAP Studio can be easily upgraded with additional plugins. "
>
>
> Do you already have these tests based on Spring-OSGi in place already
> to test out the behavior of the bundles?
Not all the bundles but some. LoggingService and Mina have
integrations tests in place. Note Logging Service will most likely be
going away as I have worked with the Ceki to replace it with an OSGi
supported Slf4j (on current slf4j trunk which is at 1.3.0-SNAPSHOT).
Full very nice integration test suite is in place over at the slf4j that
is based on Swing-OSGi.
Also please note that Spring-OSGi API is very much in a state of flux
although the testing APIs seems to be pretty stable.
The big mama test to do is the integration test suite for the
configuration admin service implementation that I committed a few weeks
ago to the sandbox. The configuration admin service sits on top of a
DAOConfigurationStore interface which in our case is a
JndiConfigurationStore implementation. The JndiConfigurationStore
depends on the InitialContextFactory service I described below.
Configuration Admin configurations are persisted in our backend and
these can be created and manipulated via Ldap or the Configuration Admin
APIs. The ConfingAdmin already has a pretty complete set of Unit tests
and Spring integration tests internal to the project but to test this
via the Spring-OSGi OSGi integration test, I will need all the bundles
we (apacheDS) have created to date. Sort of a super integration test.
(PS - My company is using the earlier version of the Configuration Admin
and all the ApacheDS bundles to configure it's secret stuff. ;-) )
>
>
> Yeah that's cool. I like that.
>
>
> Thanks for understanding.
>
> Alex
| |
| Enrique Rodriguez 2007-02-22, 1:11 am |
| On 2/9/07, 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:
> ...
> 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.
My thoughts on moving ApacheDS to OSGi:
1) I am in agreement with the priorities and timeline mentioned by
Alex and Emmanuel. There are some key enterprise features the server
needs first and I have a lot of clean-up, doco, and enhancements to
make to the protocols myself. I think we can target June and work to
get the ApacheDS house in order by then.
2) A lot has improved in OSGi-land since we first started making
ApacheDS bundles with Maven 1.0. OSGi support on jcp-open was
encouraging as well as support we've seen from members of the JBoss,
Geronimo, Spring, and Maven communities. We'll see a lot of activity
this year, making OSGi even easier to move to: 3rd-party library
support, Spring support, and drastic improvements to Maven bundle
plugin technology. To be honest, moving a year ago to OSGi would have
been a lot of effort and I think the 3 months asked for here will
allow us to get some groundwork laid in the Felix community to make
this an even easier transition.
3) I think the next step is to get all of the great thinking that was
in this thread into a Confluence page. Is this still the best
location?:
http://docs.safehaus.org/display/AP...Gi+and+ApacheDS
We can move that page over by itself, but there was some indication
that the entire site was moving?
Enrique
| |
| Alex Karasulu 2007-02-22, 1:11 am |
| Enrique,
On 2/21/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On 2/9/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> My thoughts on moving ApacheDS to OSGi:
>
> 1) I am in agreement with the priorities and timeline mentioned by
> Alex and Emmanuel. There are some key enterprise features the server
> needs first and I have a lot of clean-up, doco, and enhancements to
> make to the protocols myself. I think we can target June and work to
> get the ApacheDS house in order by then.
>
> 2) A lot has improved in OSGi-land since we first started making
> ApacheDS bundles with Maven 1.0. OSGi support on jcp-open was
> encouraging as well as support we've seen from members of the JBoss,
> Geronimo, Spring, and Maven communities. We'll see a lot of activity
> this year, making OSGi even easier to move to: 3rd-party library
> support, Spring support, and drastic improvements to Maven bundle
> plugin technology. To be honest, moving a year ago to OSGi would have
> been a lot of effort and I think the 3 months asked for here will
> allow us to get some groundwork laid in the Felix community to make
> this an even easier transition.
>
> 3) I think the next step is to get all of the great thinking that was
> in this thread into a Confluence page. Is this still the best
> location?:
>
> http://docs.safehaus.org/display/AP...Gi+and+ApacheDS
>
> We can move that page over by itself, but there was some indication
> that the entire site was moving?
It should all move but feel free to move this page into the dev section of
the 1.5 space.
Alex
| |
| Enrique Rodriguez 2007-02-22, 7:11 pm |
| On 2/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> On 2/21/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> http://docs.safehaus.org/display/AP...Gi+and+ApacheDS
>
> It should all move but feel free to move this page into the dev section of
> the 1.5 space.
OK, I moved that page and its one child to the ApacheDS v1.5 Developer's Guide:
o OSGi and ApacheDS
o OSGi Bundle Breakdown
I'll do a round of spell-check then work to get this thread into there.
Enrique
| |
| Enrique Rodriguez 2007-02-24, 1:11 am |
| On 2/22/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 2/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> OK, I moved that page and its one child to the ApacheDS v1.5 Developer's Guide:
> o OSGi and ApacheDS
> o OSGi Bundle Breakdown
>
> I'll do a round of spell-check then work to get this thread into there.
I tried to capture the requirements from this thread in Confluence:
http://cwiki.apache.org/confluence/...Gi+and+ApacheDS
I think we can use that to track requirements and log discussion.
Finer-grained issues can be compiled and added to JIRA.
Look good?
Enrique
| |
| Alex Karasulu 2007-02-24, 1:11 pm |
| Yeah it's a good start.
On 2/24/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On 2/22/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> was
> section of
> Guide:
>
> I tried to capture the requirements from this thread in Confluence:
> http://cwiki.apache.org/confluence/...Gi+and+ApacheDS
>
> I think we can use that to track requirements and log discussion.
> Finer-grained issues can be compiled and added to JIRA.
>
> Look good?
>
> Enrique
>
|
|
|
|
|