cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Preparing OSGi-ready artifacts
Date Sun, 27 Apr 2008 18:12:39 GMT
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

Mime
View raw message