Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
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
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
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
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
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
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 [EMAIL PROTECTED]
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
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
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
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
On Mon, Aug 25, 2008 at 7:41 PM, Joerg Heinicke [EMAIL PROTECTED] 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
On Thu, 21 Aug 2008, Reinhard Pötz [EMAIL PROTECTED] 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
Stefan Bodewig wrote:
On Thu, 21 Aug 2008, Reinhard Pötz [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
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
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
On Thu, Aug 21, 2008 at 4:53 PM, Reinhard Pötz [EMAIL PROTECTED] 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
+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
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
