You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2008/08/21 23:53:05 UTC
[vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
After having already discussed the details, let's make a formal decision
about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
Versioning
-------------------------------
Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla,
Maven, Apache Commons, etc.). The first release will be 3.0-alpha-1.
This will be a clear marker that is already visible when you add Cocoon
as a dependency to your build or download the artifacts manually.
Additionally all release artifacts will contain a warning message and an
explanation what "alpha" means.
SVN
-------------------------------
In order to make the life easier for people who use git-svn, I propose
to use the standard SVN directory structure:
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags
Maven
-------------------------------
We use functional names for all artifacts:
org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
org.apache.cocoon.servlet:cocoon-servlet:3.0.0
org.apache.cocoon.controller:cocoon-controller:3.0.0
org.apache.cocoon.rest:cocoon-rest:3.0.0
org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
By using the functional name as part of the groupId, Cocoon 2.2 and
Cocoon 3 can be used together without getting any problems with the
dependency resolution mechanisms of Maven or Ivy.
JAVA NAMESPACES
-------------------------------
Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
are reserved for functional names:
org.apache.cocoon.pipeline
org.apache.cocoon.sitemap
org.apache.cocoon.servlet
org.apache.cocoon.controller
org.apache.cocoon.rest
org.apache.cocoon.stringtemplate
XML NAMESPACES
-------------------------------
Corona currently uses three different namespaces in XML documents:
http://apache.org/cocoon/corona/sitemap
http://apache.org/cocoon/corona/servlet
http://apache.org/cocoon/corona/controller
These namespaces are without a version number.
Since I don't see how version numbers could help, I propose
http://apache.org/cocoon/sitemap
http://apache.org/cocoon/servlet
http://apache.org/cocoon/controller
Issue tracking
-------------------------------
I propose the creation of a COCOON3 Jira project so that Cocoon 2.x and
Cocoon 3 issues don't get mixed up.
CI
-------------------------------
Apache Infrastructure offers a managed Hudson instance. I propose to
setup a Cocoon 3 project there.
This majority vote stays open for 72 hours.
Here is my +1.
--
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 reinhard@apache.org
________________________________________________________________________
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Reinhard Pötz <re...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 21 Aug 2008, Reinhard Pötz <re...@apache.org> wrote:
>
>> CI
>> -------------------------------
>> Apache Infrastructure offers a managed Hudson instance. I propose to
>> setup a Cocoon 3 project there.
>
> If you want to give Gump a fresh start with Cocoon3, I'm more than
> willing to help.
Thanks for your offer! I will do so but probably not before the second
half of September.
--
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 reinhard@apache.org
________________________________________________________________________
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 21 Aug 2008, Reinhard Pötz <re...@apache.org> wrote:
> CI
> -------------------------------
> Apache Infrastructure offers a managed Hudson instance. I propose to
> setup a Cocoon 3 project there.
If you want to give Gump a fresh start with Cocoon3, I'm more than
willing to help.
Stefan
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
Posted by Peter Hunsberger <pe...@gmail.com>.
On Mon, Aug 25, 2008 at 7:41 PM, Joerg Heinicke <jo...@gmx.de> wrote:
> On 21.08.2008 23:53, Reinhard Pötz wrote:
>
>>
>> These namespaces are without a version number.
>>
>> Since I don't see how version numbers could help, I propose
>>
>> http://apache.org/cocoon/sitemap
>> http://apache.org/cocoon/servlet
>> http://apache.org/cocoon/controller
>
> I know I'm rather late ...
>
> Don't these version numbers just help in the same way as versioned jars
> help? It's possible to signal additional functionality or incompatibilities.
> Just look at the Spring framework.
>
Sure, but you can always add them as you need them:
eg. http://apache.org/cocoon/sitemap-3.1
can come along if it is needed.
--
Peter Hunsberger
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces,
issue tracking and CI
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-08-27 at 10:41 +0200, Thorsten Scherler wrote:
> On Wed, 2008-08-27 at 10:03 +0200, Grzegorz Kossakowski wrote:
> > Thorsten Scherler pisze:
> ...
> > > I expected since I am now using Cocoon Spring Configurator 2.0 I needed
> > > to update as well
> > > http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd to http://cocoon.apache.org/schema/configurator/cocoon-configurator-2.0.0.xsd
> > > but that is not the case. Which is kind of confusing.
> >
> > Actually, you should update the schema but the schema is located at
> > http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.1.0.xsd
> > because we planned to release 1.1.0 instead of 2.0.0 and once decision was made to release 2.0.0 it
> > was forgotten to rename this file.
> >
> > Could you take care of it?
>
> Sure, however not sure about the publishing process. Is
> svn mv
> https://svn.apache.org/repos/asf/cocoon/site/site/schema/configurator/cocoon-configurator-1.1.0.xsd https://svn.apache.org/repos/asf/cocoon/site/site/schema/configurator/cocoon-configurator-2.0.0.xsd
>
> enough?
>
> Or do I need to move it from the source?
Committed revision 689438.
I copied instead of mv. If anything else needs to be done please let me
know.
salu2
>
>
> >
> >
> > > BTW since we are now using 2.5 shouldn't we update our config files to
> > > reflect this?
> >
> > Probably a good idea.
>
>
> Will try to take of it.
>
> salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces,
issue tracking and CI
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-08-27 at 10:03 +0200, Grzegorz Kossakowski wrote:
> Thorsten Scherler pisze:
...
> > I expected since I am now using Cocoon Spring Configurator 2.0 I needed
> > to update as well
> > http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd to http://cocoon.apache.org/schema/configurator/cocoon-configurator-2.0.0.xsd
> > but that is not the case. Which is kind of confusing.
>
> Actually, you should update the schema but the schema is located at
> http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.1.0.xsd
> because we planned to release 1.1.0 instead of 2.0.0 and once decision was made to release 2.0.0 it
> was forgotten to rename this file.
>
> Could you take care of it?
Sure, however not sure about the publishing process. Is
svn mv
https://svn.apache.org/repos/asf/cocoon/site/site/schema/configurator/cocoon-configurator-1.1.0.xsd https://svn.apache.org/repos/asf/cocoon/site/site/schema/configurator/cocoon-configurator-2.0.0.xsd
enough?
Or do I need to move it from the source?
>
>
> > BTW since we are now using 2.5 shouldn't we update our config files to
> > reflect this?
>
> Probably a good idea.
Will try to take of it.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces,
issue tracking and CI
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-08-27 at 10:03 +0200, Grzegorz Kossakowski wrote:
...
> > BTW since we are now using 2.5 shouldn't we update our config files to
> > reflect this?
>
> Probably a good idea.
done.
Committed revision 689429.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Thorsten Scherler pisze:
> On Tue, 2008-08-26 at 09:26 +0200, Andreas Hartmann wrote:
>> Joerg Heinicke schrieb:
>>
>> […]
>>
>>>> XML NAMESPACES
>>>> -------------------------------
>>>> Corona currently uses three different namespaces in XML documents:
>>>>
>>>> http://apache.org/cocoon/corona/sitemap
>>>> http://apache.org/cocoon/corona/servlet
>>>> http://apache.org/cocoon/corona/controller
>>>>
>>>> These namespaces are without a version number.
>>>>
>>>> Since I don't see how version numbers could help, I propose
>>>>
>>>> http://apache.org/cocoon/sitemap
>>>> http://apache.org/cocoon/servlet
>>>> http://apache.org/cocoon/controller
>>> I know I'm rather late ...
>>>
>>> Don't these version numbers just help in the same way as versioned jars
>>> help? It's possible to signal additional functionality or
>>> incompatibilities. Just look at the Spring framework.
>> IMO version numbers in namespaces do more harm than good. From a user's
>> point of view it needs much concentration to avoid mistakes if more than
>> one namespace is available for a particular markup. If the namespace
>> changes when functionality is added (e.g., a document format becomes
>> more expressive), it's not backwards compatible anymore, i.e. components
>> handling the namespace have to be updated.
>>
>> If the changes are not backwards-compatible:
>> In some cases additional markup can be used to express the version (like
>> for instance the version attribute in XSLT). Where this is not possible,
>> it might make sense to create a new meaningful namespace URI.
>
> I totally agree with Andreas regarding the versions in ns.
>
> http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/2.0/1303_1_1.html
>
> I expected since I am now using Cocoon Spring Configurator 2.0 I needed
> to update as well
> http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd to http://cocoon.apache.org/schema/configurator/cocoon-configurator-2.0.0.xsd
> but that is not the case. Which is kind of confusing.
Actually, you should update the schema but the schema is located at
http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.1.0.xsd
because we planned to release 1.1.0 instead of 2.0.0 and once decision was made to release 2.0.0 it
was forgotten to rename this file.
Could you take care of it?
> BTW since we are now using 2.5 shouldn't we update our config files to
> reflect this?
Probably a good idea.
--
Grzegorz Kossakowski
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue
tracking and CI
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2008-08-26 at 09:26 +0200, Andreas Hartmann wrote:
> Joerg Heinicke schrieb:
>
> […]
>
> >> XML NAMESPACES
> >> -------------------------------
> >> Corona currently uses three different namespaces in XML documents:
> >>
> >> http://apache.org/cocoon/corona/sitemap
> >> http://apache.org/cocoon/corona/servlet
> >> http://apache.org/cocoon/corona/controller
> >>
> >> These namespaces are without a version number.
> >>
> >> Since I don't see how version numbers could help, I propose
> >>
> >> http://apache.org/cocoon/sitemap
> >> http://apache.org/cocoon/servlet
> >> http://apache.org/cocoon/controller
> >
> > I know I'm rather late ...
> >
> > Don't these version numbers just help in the same way as versioned jars
> > help? It's possible to signal additional functionality or
> > incompatibilities. Just look at the Spring framework.
>
> IMO version numbers in namespaces do more harm than good. From a user's
> point of view it needs much concentration to avoid mistakes if more than
> one namespace is available for a particular markup. If the namespace
> changes when functionality is added (e.g., a document format becomes
> more expressive), it's not backwards compatible anymore, i.e. components
> handling the namespace have to be updated.
>
> If the changes are not backwards-compatible:
> In some cases additional markup can be used to express the version (like
> for instance the version attribute in XSLT). Where this is not possible,
> it might make sense to create a new meaningful namespace URI.
I totally agree with Andreas regarding the versions in ns.
http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/2.0/1303_1_1.html
I expected since I am now using Cocoon Spring Configurator 2.0 I needed
to update as well
http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd to http://cocoon.apache.org/schema/configurator/cocoon-configurator-2.0.0.xsd
but that is not the case. Which is kind of confusing.
For example spring is different in this regard there I could change
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd to
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
BTW since we are now using 2.5 shouldn't we update our config files to
reflect this?
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Andreas Hartmann <an...@apache.org>.
Joerg Heinicke schrieb:
[…]
>> XML NAMESPACES
>> -------------------------------
>> Corona currently uses three different namespaces in XML documents:
>>
>> http://apache.org/cocoon/corona/sitemap
>> http://apache.org/cocoon/corona/servlet
>> http://apache.org/cocoon/corona/controller
>>
>> These namespaces are without a version number.
>>
>> Since I don't see how version numbers could help, I propose
>>
>> http://apache.org/cocoon/sitemap
>> http://apache.org/cocoon/servlet
>> http://apache.org/cocoon/controller
>
> I know I'm rather late ...
>
> Don't these version numbers just help in the same way as versioned jars
> help? It's possible to signal additional functionality or
> incompatibilities. Just look at the Spring framework.
IMO version numbers in namespaces do more harm than good. From a user's
point of view it needs much concentration to avoid mistakes if more than
one namespace is available for a particular markup. If the namespace
changes when functionality is added (e.g., a document format becomes
more expressive), it's not backwards compatible anymore, i.e. components
handling the namespace have to be updated.
If the changes are not backwards-compatible:
In some cases additional markup can be used to express the version (like
for instance the version attribute in XSLT). Where this is not possible,
it might make sense to create a new meaningful namespace URI.
Just my $0.02, I'd be very interested in the opionions of others.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
Posted by Joerg Heinicke <jo...@gmx.de>.
Reinhard Pötz <reinhard <at> apache.org> writes:
> >> XML NAMESPACES
> >> -------------------------------
> >> Since I don't see how version numbers could help, I propose
> >
> > Don't these version numbers just help in the same way as versioned jars
> > help? It's possible to signal additional functionality or
> > incompatibilities. Just look at the Spring framework.
>
> We did look at the Spring framework and they don't use versioned
> namespaces, e.g. http://www.springframework.org/schema/beans, but only
> versioned XSDs.
Oh, I'm sorry I had XSDs in mind when you wrote about namespaces. So please
ignore my last mail.
> IMO versioned XSDs are all you need to signal additional functionality
> or incompatibilities.
I agree. So +1 one for your proposal.
Joerg
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Reinhard Pötz <re...@apache.org>.
Joerg Heinicke wrote:
> On 21.08.2008 23:53, Reinhard Pötz wrote:
>
>> After having already discussed the details, let's make a formal decision
>> about versioning, SVN, Maven, namespaces issue tracking and CI for
>> Cocoon 3.
>
> +1 to everything except ...
>
>> XML NAMESPACES
>> -------------------------------
>> Corona currently uses three different namespaces in XML documents:
>>
>> http://apache.org/cocoon/corona/sitemap
>> http://apache.org/cocoon/corona/servlet
>> http://apache.org/cocoon/corona/controller
>>
>> These namespaces are without a version number.
>>
>> Since I don't see how version numbers could help, I propose
>>
>> http://apache.org/cocoon/sitemap
>> http://apache.org/cocoon/servlet
>> http://apache.org/cocoon/controller
>
> I know I'm rather late ...
>
> Don't these version numbers just help in the same way as versioned jars
> help? It's possible to signal additional functionality or
> incompatibilities. Just look at the Spring framework.
We did look at the Spring framework and they don't use versioned
namespaces, e.g. http://www.springframework.org/schema/beans, but only
versioned XSDs.
Versioned namespaces aren't of much help because the sitemap language
interpreter has to validate the XML in some way - checking the namespace
isn't good enough anyway.
IMO versioned XSDs are all you need to signal additional functionality
or incompatibilities.
--
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 reinhard@apache.org
________________________________________________________________________
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Joerg Heinicke <jo...@gmx.de>.
On 21.08.2008 23:53, Reinhard Pötz wrote:
> After having already discussed the details, let's make a formal decision
> about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
+1 to everything except ...
> XML NAMESPACES
> -------------------------------
> Corona currently uses three different namespaces in XML documents:
>
> http://apache.org/cocoon/corona/sitemap
> http://apache.org/cocoon/corona/servlet
> http://apache.org/cocoon/corona/controller
>
> These namespaces are without a version number.
>
> Since I don't see how version numbers could help, I propose
>
> http://apache.org/cocoon/sitemap
> http://apache.org/cocoon/servlet
> http://apache.org/cocoon/controller
I know I'm rather late ...
Don't these version numbers just help in the same way as versioned jars
help? It's possible to signal additional functionality or
incompatibilities. Just look at the Spring framework.
> CI
> -------------------------------
> Apache Infrastructure offers a managed Hudson instance. I propose to
> setup a Cocoon 3 project there.
I'd like to see continuous integration, be it Continuum, Hudson or Gump.
Joerg
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Felix Knecht <fe...@apache.org>.
Reinhard Pötz schrieb:
> After having already discussed the details, let's make a formal decision
> about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
>
>
+1
Felix
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Ralph Goers <Ra...@dslextreme.com>.
+1
Reinhard Pötz wrote:
> After having already discussed the details, let's make a formal decision
> about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
>
> Versioning
> -------------------------------
> Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla,
> Maven, Apache Commons, etc.). The first release will be 3.0-alpha-1.
>
> This will be a clear marker that is already visible when you add Cocoon
> as a dependency to your build or download the artifacts manually.
>
> Additionally all release artifacts will contain a warning message and an
> explanation what "alpha" means.
>
> SVN
> -------------------------------
> In order to make the life easier for people who use git-svn, I propose
> to use the standard SVN directory structure:
>
> http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk
> http://svn.apache.org/repos/asf/cocoon/cocoon3/tags
>
> Maven
> -------------------------------
> We use functional names for all artifacts:
>
> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
> org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
> org.apache.cocoon.servlet:cocoon-servlet:3.0.0
> org.apache.cocoon.controller:cocoon-controller:3.0.0
> org.apache.cocoon.rest:cocoon-rest:3.0.0
> org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
>
> By using the functional name as part of the groupId, Cocoon 2.2 and
> Cocoon 3 can be used together without getting any problems with the
> dependency resolution mechanisms of Maven or Ivy.
>
> JAVA NAMESPACES
> -------------------------------
> Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
> are reserved for functional names:
>
> org.apache.cocoon.pipeline
> org.apache.cocoon.sitemap
> org.apache.cocoon.servlet
> org.apache.cocoon.controller
> org.apache.cocoon.rest
> org.apache.cocoon.stringtemplate
>
> XML NAMESPACES
> -------------------------------
> Corona currently uses three different namespaces in XML documents:
>
> http://apache.org/cocoon/corona/sitemap
> http://apache.org/cocoon/corona/servlet
> http://apache.org/cocoon/corona/controller
>
> These namespaces are without a version number.
>
> Since I don't see how version numbers could help, I propose
>
> http://apache.org/cocoon/sitemap
> http://apache.org/cocoon/servlet
> http://apache.org/cocoon/controller
>
> Issue tracking
> -------------------------------
> I propose the creation of a COCOON3 Jira project so that Cocoon 2.x and
> Cocoon 3 issues don't get mixed up.
>
> CI
> -------------------------------
> Apache Infrastructure offers a managed Hudson instance. I propose to
> setup a Cocoon 3 project there.
>
>
> This majority vote stays open for 72 hours.
>
> Here is my +1.
>
>
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
Posted by Peter Hunsberger <pe...@gmail.com>.
On Thu, Aug 21, 2008 at 4:53 PM, Reinhard Pötz <re...@apache.org> wrote:
>
> After having already discussed the details, let's make a formal decision
> about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
>
+1
--
Peter Hunsberger
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking
and CI
Posted by Andreas Hartmann <an...@apache.org>.
Reinhard Pötz schrieb:
> After having already discussed the details, let's make a formal decision
> about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
+1
I'm looking forward to the new version!
-- Andreas
>
> Versioning
> -------------------------------
> Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla,
> Maven, Apache Commons, etc.). The first release will be 3.0-alpha-1.
>
> This will be a clear marker that is already visible when you add Cocoon
> as a dependency to your build or download the artifacts manually.
>
> Additionally all release artifacts will contain a warning message and an
> explanation what "alpha" means.
>
> SVN
> -------------------------------
> In order to make the life easier for people who use git-svn, I propose
> to use the standard SVN directory structure:
>
> http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk
> http://svn.apache.org/repos/asf/cocoon/cocoon3/tags
>
> Maven
> -------------------------------
> We use functional names for all artifacts:
>
> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
> org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
> org.apache.cocoon.servlet:cocoon-servlet:3.0.0
> org.apache.cocoon.controller:cocoon-controller:3.0.0
> org.apache.cocoon.rest:cocoon-rest:3.0.0
> org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
>
> By using the functional name as part of the groupId, Cocoon 2.2 and
> Cocoon 3 can be used together without getting any problems with the
> dependency resolution mechanisms of Maven or Ivy.
>
> JAVA NAMESPACES
> -------------------------------
> Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
> are reserved for functional names:
>
> org.apache.cocoon.pipeline
> org.apache.cocoon.sitemap
> org.apache.cocoon.servlet
> org.apache.cocoon.controller
> org.apache.cocoon.rest
> org.apache.cocoon.stringtemplate
>
> XML NAMESPACES
> -------------------------------
> Corona currently uses three different namespaces in XML documents:
>
> http://apache.org/cocoon/corona/sitemap
> http://apache.org/cocoon/corona/servlet
> http://apache.org/cocoon/corona/controller
>
> These namespaces are without a version number.
>
> Since I don't see how version numbers could help, I propose
>
> http://apache.org/cocoon/sitemap
> http://apache.org/cocoon/servlet
> http://apache.org/cocoon/controller
>
> Issue tracking
> -------------------------------
> I propose the creation of a COCOON3 Jira project so that Cocoon 2.x and
> Cocoon 3 issues don't get mixed up.
>
> CI
> -------------------------------
> Apache Infrastructure offers a managed Hudson instance. I propose to
> setup a Cocoon 3 project there.
>
>
> This majority vote stays open for 72 hours.
>
> Here is my +1.
>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
[summary][vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue
tracking and CI
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> After having already discussed the details, let's make a formal decision
> about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
During the voting period there were no negative votes, and 6 positive
ones. This means that the proposal was accepted.
I will take care of all the refactorings and infrastructure requests in
the second half of September after my vacations.
--
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 reinhard@apache.org
________________________________________________________________________