cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Preparing OSGi-ready artifacts
Date Sun, 27 Apr 2008 16:41:30 GMT
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


Mime
View raw message