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