You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2008/04/25 23:02:30 UTC
Preparing OSGi-ready artifacts
Hi folks,
I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very good to me. I'm thinking about
releasing first milestone of this module (along with cocoon-jnet) but I've been struck by a little
mess in packages we have in SSF and cocoon-jnet.
Let's have a look at SSF, we have following packages:
o.a.c.callstack.*
o.a.c.servletscope.*
o.a.c.servletservice.*
Now cocoon-jnet:
o.a.c.jnet.*
o.a.excalibur.sourceresolve.jnet.*
This brings us to couple of questions:
1. Do we want to have a policy to have only one base package (e.g. o.a.c.servletservice.*) per one
module (artifact, JAR, you name it)?
2. What OSGi folks can say about this situation? I remember that there was some requirement to have
clean package structure in order to run in OSGi environment easily but I'm not expert in this area.
3. Why cocoon-jnet has excalibur-specific classes at all? I thought that we agreed we are not going
to support Sources as URLs and only focus on new functionality. Then
o.a.excalibur.sourceresolve.jnet.* should be removed right?
--
Grzegorz Kossakowski
Releasing Cocoon subprojects
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Hi folks,
>
> I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very
> good to me. I'm thinking about releasing first milestone of this module
> (along with cocoon-jnet)
If you release SSF 1.1.0, also cocoon-blockdeployment,
cocoon-configuration, cocoon-spring-configurator and as you proposed
cocoon-jnet should be released.
Additionally it's probably a good idea to release the Cocoon Maven
plugin and the archetypes.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
________________________________________________________________________
Re: Preparing OSGi-ready artifacts
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>> Grzegorz Kossakowski wrote:
>>> This brings us to couple of questions:
>>> 1. Do we want to have a policy to have only one base package (e.g.
>>> o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
>>> 2. What OSGi folks can say about this situation? I remember that
>>> there was some requirement to have clean package structure in order
>>> to run in OSGi environment easily but I'm not expert in this area.
>> There shouldn't be two different artifacts *exporting* the same
>> package, which means having classes intendet to be used by other
>> artifacts in this package. That's afaik the only requirement for OSGi.
>>
>> This can be easily reached if a block uses o.a.c.{blockname} for its
>> own packages.
>
> So do you think we need to rename o.a.c.callstack into
> o.a.c.servletservice.callstack ?
IMO, no. It doesn't violate the rule that there shouldn't be two
different artifacts exporting the same package.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
________________________________________________________________________
Re: Preparing OSGi-ready artifacts
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Carsten Ziegeler pisze:
> Grzegorz Kossakowski wrote:
>> This brings us to couple of questions:
>> 1. Do we want to have a policy to have only one base package (e.g.
>> o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
>> 2. What OSGi folks can say about this situation? I remember that there
>> was some requirement to have clean package structure in order to run
>> in OSGi environment easily but I'm not expert in this area.
> There shouldn't be two different artifacts *exporting* the same package,
> which means having classes intendet to be used by other artifacts in
> this package. That's afaik the only requirement for OSGi.
>
> This can be easily reached if a block uses o.a.c.{blockname} for its own
> packages.
So do you think we need to rename o.a.c.callstack into o.a.c.servletservice.callstack ?
--
Grzegorz Kossakowski
Re: Preparing OSGi-ready artifacts
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> This brings us to couple of questions:
> 1. Do we want to have a policy to have only one base package (e.g.
> o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
> 2. What OSGi folks can say about this situation? I remember that there
> was some requirement to have clean package structure in order to run in
> OSGi environment easily but I'm not expert in this area.
There shouldn't be two different artifacts *exporting* the same package,
which means having classes intendet to be used by other artifacts in
this package. That's afaik the only requirement for OSGi.
This can be easily reached if a block uses o.a.c.{blockname} for its own
packages.
Carstem
--
Carsten Ziegeler
cziegeler@apache.org
Re: Preparing OSGi-ready artifacts
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Hi folks,
>>
>> I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very
>> good to me. I'm thinking about releasing first milestone of this
>> module (along with cocoon-jnet) but I've been struck by a little mess
>> in packages we have in SSF and cocoon-jnet.
>>
>> Let's have a look at SSF, we have following packages:
>>
>> o.a.c.callstack.*
>> o.a.c.servletscope.*
>> o.a.c.servletservice.*
>
> The reason that I used a separate top level package for the
> o.a.c.callstack was that I had some idea about using it as some kind of
> generic call stack for the site map engine (and move it to an own
> module). That would have required some refactoring that I never felt
> motivated enough to pursue.
> I don't know (or remember if I was responsible ;) ) about the
> o.a.c.servletscope package.
Ok, that was me who introduced this one. ;-)
> As o.a.c.callstack.* probably isn't useful outside the context of
> servlet services and only used in the implementation it might be safe to
> move it to o.a.c.servletservice.callstack.*
Agreed. Will do this shortly.
>> Now cocoon-jnet:
>> o.a.c.jnet.*
>> o.a.excalibur.sourceresolve.jnet.*
>>
>>
>> This brings us to couple of questions:
>> 1. Do we want to have a policy to have only one base package (e.g.
>> o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
>
> That is preferable. But it is not necessary. If a module already
> contains several "top level" packages that people are using, it might
> not be worthwhile to introduce back incompatibility just for the sake of
> minor elegance.
Yep, but if we introduce back incompatibility for some other reason I think we should take the
opportunity to clean up packages as well.
>> 2. What OSGi folks can say about this situation? I remember that there
>> was some requirement to have clean package structure in order to run
>> in OSGi environment easily but I'm not expert in this area.
>
> The requirement for making OSGi use possible is the opposite way around.
> Two modules cannot use the same package. If two modules (bundles) add
> different classes to the same package just the classes from one of the
> module will be available in the OSGi framework.
>
> An example of this problem is the package o.a.c.generation that is
> populated with interfaces and implementations in numerous modules.
>
> But neither cocoon-jnet nor SSF has any such problems AFAIK.
I see. Thanks for clarifying.
--
Grzegorz Kossakowski
Re: Preparing OSGi-ready artifacts
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hi folks,
>
> I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very
> good to me. I'm thinking about releasing first milestone of this module
> (along with cocoon-jnet) but I've been struck by a little mess in
> packages we have in SSF and cocoon-jnet.
>
> Let's have a look at SSF, we have following packages:
>
> o.a.c.callstack.*
> o.a.c.servletscope.*
> o.a.c.servletservice.*
The reason that I used a separate top level package for the
o.a.c.callstack was that I had some idea about using it as some kind of
generic call stack for the site map engine (and move it to an own
module). That would have required some refactoring that I never felt
motivated enough to pursue.
I don't know (or remember if I was responsible ;) ) about the
o.a.c.servletscope package.
As o.a.c.callstack.* probably isn't useful outside the context of
servlet services and only used in the implementation it might be safe to
move it to o.a.c.servletservice.callstack.*
> Now cocoon-jnet:
> o.a.c.jnet.*
> o.a.excalibur.sourceresolve.jnet.*
>
>
> This brings us to couple of questions:
> 1. Do we want to have a policy to have only one base package (e.g.
> o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
That is preferable. But it is not necessary. If a module already
contains several "top level" packages that people are using, it might
not be worthwhile to introduce back incompatibility just for the sake of
minor elegance.
> 2. What OSGi folks can say about this situation? I remember that there
> was some requirement to have clean package structure in order to run in
> OSGi environment easily but I'm not expert in this area.
The requirement for making OSGi use possible is the opposite way around.
Two modules cannot use the same package. If two modules (bundles) add
different classes to the same package just the classes from one of the
module will be available in the OSGi framework.
An example of this problem is the package o.a.c.generation that is
populated with interfaces and implementations in numerous modules.
But neither cocoon-jnet nor SSF has any such problems AFAIK.
> 3. Why cocoon-jnet has excalibur-specific classes at all? I thought that
> we agreed we are not going to support Sources as URLs and only focus on
> new functionality. Then o.a.excalibur.sourceresolve.jnet.* should be
> removed right?
Don't know.
/Daniel
Re: Finding a home for JNet
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Pötz wrote
>>
>> My proposal
>> -----------
>>
>> * I think we should contact the Apache Commons community and talk with
>> them about org.apache.excalibur.sourceresolve.jnet stuff.
>>
>> * Since I don't expect that we can release it from there anytime soon, I
>> think we should release it for now ourselves using our own namespace.
>> As soon as there is the other release available, we can switch and
>> deprecate our own implementation.
>>
>> * The org.apache.excalibur.sourceresolve.jnet.source stuff can be
>> removed from our repository completely because we don't use it.
>> It should be used by the Apache Excalibur project.
>>
> Sounds like a good plan to me.
>
>> Who's going to contact the Apache Commons community? Carsten, do you
>> want to do it yourself? I think the credit is due to you!
> :) Thanks, yepp, I'll contact them later today. Perhaps we are lucky and
> it doesn't take too long to get a proper commons release.
Thanks!
The two classes can be found at
http://svn.eu.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-jnet/src/main/java/org/apache/excalibur/sourceresolve/jnet/
(afaik only this mirror is currently available).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
________________________________________________________________________
Re: Finding a home for JNet
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Pötz wrote
>
> My proposal
> -----------
>
> * I think we should contact the Apache Commons community and talk with
> them about org.apache.excalibur.sourceresolve.jnet stuff.
>
> * Since I don't expect that we can release it from there anytime soon, I
> think we should release it for now ourselves using our own namespace.
> As soon as there is the other release available, we can switch and
> deprecate our own implementation.
>
> * The org.apache.excalibur.sourceresolve.jnet.source stuff can be
> removed from our repository completely because we don't use it.
> It should be used by the Apache Excalibur project.
>
Sounds like a good plan to me.
> Who's going to contact the Apache Commons community? Carsten, do you
> want to do it yourself? I think the credit is due to you!
:) Thanks, yepp, I'll contact them later today. Perhaps we are lucky and
it doesn't take too long to get a proper commons release.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Finding a home for JNet
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Now cocoon-jnet:
> o.a.c.jnet.*
> o.a.excalibur.sourceresolve.jnet.*
This brings us to the question of the final home of cocoon-jnet. It was
originally developed by Carsten as part of the Excalibur project. It
provides a mechanism to _dynamically_ register your own
URLStreamHandlerFactory implementations
(org.apache.excalibur.sourceresolve.jnet.*)
Additionally JNet contains a special URLStreamHandlerFactory that allows
you to register Excalibur sources
(org.apache.excalibur.sourceresolve.jnet.source.*) which then become
useable together with java.net.URL.
Currently we only use org.apache.excalibur.sourceresolve.jnet because we
want to register servlet:/ and blockcontext:/ URLs using JNet instead of
excalibur-sourceresolve. By doing this cocoon-servlet-service-impl and
cocoon-blockdeployment don't have a hard dependency on Excalibur anymore.
(BTW, Cocoon 2.2 still has but I don't think it's worthwhile to cut this
dependency there too.)
The question now is how/where we want to release JNet. I think that it
is an intersting piece of code for everybody who wants to register his
own URLStreamHandlerFactory implementations and can't be sure that he is
the first or the only one who wants to do this. Having only one
defacto-standard in the Java world would be great.
IMO the best fit is Apache Commons for
org.apache.excalibur.sourceresolve.jnet (2 classes) and Apache Excalibur
for org.apache.excalibur.sourceresolve.jnet.source (7 classes).
My proposal
-----------
* I think we should contact the Apache Commons community and talk with
them about org.apache.excalibur.sourceresolve.jnet stuff.
* Since I don't expect that we can release it from there anytime soon, I
think we should release it for now ourselves using our own namespace.
As soon as there is the other release available, we can switch and
deprecate our own implementation.
* The org.apache.excalibur.sourceresolve.jnet.source stuff can be
removed from our repository completely because we don't use it.
It should be used by the Apache Excalibur project.
Who's going to contact the Apache Commons community? Carsten, do you
want to do it yourself? I think the credit is due to you!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
________________________________________________________________________