cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: A new name for Corona (take 2)
Date Tue, 05 Aug 2008 11:31:29 GMT
Daniel Fagerstrom wrote:

it's great to see you here again!

> 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.

Thanks for the reminder. I was too much influenced by thinking of OSGi.

I also believe you're right that it is very unlikely that Cocoon 2.2 
will ever be migrated to OSGi.

> But do you really think it will be worthwhile to make it possible to use 
> Cocoon 2.2 and 3.0 together? 

yes, if you have a large Cocoon 2.2 application and you want to use 
Cocoon 3.0 to provide RESTful services. Cocoon 3.0 will be optimized for 
this use case.

> 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.

I haven't thought about this yet but you're probably right. I'd say that 
we keep the door open and see if using 2.2 and 3.0 together is a valid 
use case that happens in practice.

> Anyway I would suggest:
> org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
> org.apache.cocoon.sitemap:cocoon-sitemap:3.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 ->
> org.apache.cocoon.servlet:cocoon-servlet:3.0.0
> Here the only conflict (that I found) is SitemapParameters, what about 
> SitemapParameterMap or maybe just Parameters?

thanks for your investigations. When I do the migration to the new 
artifactId/groupId/package names, I will rename the two classes.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message