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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
________________________________________________________________________
