cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: A new name for Corona (take 2)
Date Tue, 05 Aug 2008 11:12:36 GMT
Reinhard Pötz skrev:
> Carsten Ziegeler wrote:
>> Reinhard Pötz wrote:
>>>> You guys have finally convinced me. Let's use 3.0.x for Corona, 
>>>> clearly state that it is alpha software on the website in the 
>>>> README.txt of each release artifact and see what's happening.
>>>> Then we only need to find a package name that isn't used in trunk 
>>>> because Corona should run in parallel with Cocoon 2.2 without a 
>>>> problem (haven't tried it yet but at least in theory).
>>>> The simplest solution would be keeping 'corona' as part of the 
>>>> package name (org.apache.cocoon.corona). IIRC Tomcat also kept the 
>>>> 'catalina' package names.
>>>> Any other suggestions?
>>> I forgot to mention that we also have to find unique Maven artifact 
>>> IDs for the reasons explained above.
>> Great, I'm fine with using 3.0.x as well.
>> For the package names and artifact ids, I'm not sure if we should 
>> keep corona inside. 
> I would have been fine for package names since they are internal, but 
> not for artifactIds or groupIds.
>> I would prefer to simply use different functional package names. And 
>> if we use the package names as group ids, we're fine.
> org.apache.cocoon.corona:corona-pipeline:1.0.0 ->
> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
> org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
> org.apache.cocoon.sitemap.language.xml:cocoon-sitemap-language-xml:3.0.0
> org.apache.cocoon.corona:corona-controller:1.0.0 ->
> org.apache.cocoon.controller:cocoon-controller:3.0.0
> org.apache.cocoon.corona:corona-servlet:1.0.0 ->
> org.apache.cocoon.http.servlet:cocoon-http-servlet:3.0.0
> any better ideas? (org.apache.cocoon.servlet is already in use)
First I agree with using 3.0.x. Second for the package names I don't see 
that it should be a problem to reuse package names from Cocoon 2.2. If 
we want to be able to use Cocoon with OSGi it is imortant that a package 
only is exported from one module (bundle). But the package structure in 
Cocoon 2.2 is so messed up so it is not possible to use Cocoon 2.2 
together with OSGi in any practical way anyway. So from an OSGi POV the 
only important thing is to make the package structure of "Cocoon 3.0" 
OSGi friendly. For coexistence between "Cocoon 3.0" blocks and Cocoon 
2.2 it is enough if the classes are different.

But do you really think it will be worthwhile to make it possible to use 
Cocoon 2.2 and 3.0 together? While it might be possible with not to much 
work for the Corona stuff, I guess it will start to be rather painfull 
once people start to upgrade some of our blocks to 3.0.

Anyway I would suggest:

org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
The only class name conflict here is SitemapServlet maybe we could use 
XmlSitemapServlet instead.

org.apache.cocoon.corona:corona-servlet:1.0.0 ->
Here the only conflict (that I found) is SitemapParameters, what about 
SitemapParameterMap or maybe just Parameters?


View raw message