I really do not understand the advantage of this. Right now when I log into Jira and select Cocoon I can see all the Cocoon blocks. Obviously being able to associate an issue with a block or search or filter by block is therefore not an issue. The reason I keep hearing is that this should be done so that each block can be independently versioned. But I don't see why that can't be done now. Can we not just create versions such as Ajax-1.0?

On the down side, right now if I log into Jira I can see all the Cocoon issues fairly easily. Is there any way to do that once they are split? Furthermore, I already don't like that the list of projects on the main page is riddled with a bunch of stuff from Commons. But at least there everyone knows that Commons is just a bunch of Java utilities, each of which is independent of each other. In our case this isn't really true. If, in fact, any of the items in the list below is truly independent perhaps it should be split from Cocoon entirely, not just in Jira. For example, I recall that Spring configurator would fit into this category.

Ralph

Grzegorz Kossakowski wrote:
Hi,

We have discussed JIRA split up several times now, the last time in this thread[1]. Since infra team raised concerns on proposed JIRA project identifier we agreed on adding "COCOON" prefix to every identifier. I posted updated proposal with topic "Division of Cocoon's JIRA once again" asking if there are any objections and for month there have been none.

I would like call vote on division of Cocoon's JIRA project into several smaller ones as outlined below.
The list of projects with proposed JIRA identifiers in brackets:
- Cocoon Core (COCOONCORE)
  includes following artifacts:
  * org.apache.cocoon:cocoon-pipeline-api
  * org.apache.cocoon:cocoon-util
  * org.apache.cocoon:cocoon-xml-api
  * org.apache.cocoon:cocoon-pipeline-impl
  * org.apache.cocoon:cocoon-xml-impl
  * org.apache.cocoon:cocoon-pipeline-components
  * org.apache.cocoon:cocoon-sitemap-api
  * org.apache.cocoon:cocoon-thread-api
  * org.apache.cocoon:cocoon-sitemap-impl
  * org.apache.cocoon:cocoon-sitemap-components
  * org.apache.cocoon:cocoon-xml-resolver
  * org.apache.cocoon:cocoon-store-impl
  * org.apache.cocoon:cocoon-thread-impl
  * org.apache.cocoon:cocoon-core
  * org.apache.cocoon:cocoon-core-main-sample
  * org.apache.cocoon:cocoon-expression-language-api
  * org.apache.cocoon:cocoon-expression-language-impl
- Servlet service framework (COCOONSERVLETSERVICE)
  * org.apache.cocoon:cocoon-servlet-service-components
  * org.apache.cocoon:cocoon-servlet-service-impl
  * org.apache.cocoon:cocoon-servlet-service-sample
- Template (COCOONTEMPLATE)
  * org.apache.cocoon:cocoon-template-impl
  * org.apache.cocoon:cocoon-template-sample
- Flowscript (COCOONFLOWSCRIPT)
  * org.apache.cocoon:cocoon-flowscript-impl
- Database (COCOONDATABASE)
  * org.apache.cocoon:cocoon-databases-mocks
  * org.apache.cocoon:cocoon-databases-hsqldb-server
  * org.apache.cocoon:cocoon-databases-hsqldb-client
  * org.apache.cocoon:cocoon-databases-impl
- Forms (COCOONFORMS)
  * org.apache.cocoon:cocoon-forms-impl
  * org.apache.cocoon:cocoon-forms-sample
- M2 Plugins and archetypes (COCOONM2)
  * org.apache.cocoon:cocoon-maven-plugin
  * org.apache.cocoon:cocoon-rcl-spring-reloader
  * org.apache.cocoon:cocoon-rcl-webapp-wrapper
  * org.apache.cocoon:cocoon-22-archetype-block
  * org.apache.cocoon:cocoon-22-archetype-block-plain
  * org.apache.cocoon:cocoon-22-archetype-webapp

Please cast your votes!

[1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/73844

Reply via email to