You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/08/15 14:03:15 UTC
[VOTE] Division of Cocoon's JIRA project
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
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
>> hmmm, the main benefit of having seperate Jira projects is that we
>> can have seperate version numbering schemes for each project.
>
> I think it makes sense to not introduce a separate Jira project for
> EVERY project that might have (or already has) a different version
> number. See also COCOONBLOCKS above. Having the list of versions reduced
> to a meaningful set of this group is already advantageous.
What's the benefit of having seperate Jira projects for a group of Cocoon
modules compared to our current situation of having components in Jira?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 15.08.2007 8:13 Uhr, Carsten Ziegeler wrote:
> - why are some modules from cocoon core not listed under cocooncore?
> - why a separate Jira project for the servletservice? and why not for
> others that mind stand on their own?
> - why separate projects for some blocks? Why exactly these?
> - what about the remaining blocks?
These are probably the so-called "core blocks" that we are going to
release with Cocoon Core 2.2. If other blocks justify their own project
in the future we can add them as well. The most important should be to
get a start. The list only lacks a project for all the "other blocks",
COCOONBLOCKS should be ok.
On 15.08.2007 8:18 Uhr, Reinhard Poetz wrote:
> hmmm, the main benefit of having seperate Jira projects is that we
> can have seperate version numbering schemes for each project.
I think it makes sense to not introduce a separate Jira project for
EVERY project that might have (or already has) a different version
number. See also COCOONBLOCKS above. Having the list of versions reduced
to a meaningful set of this group is already advantageous.
> Apart fromt that I miss COCOONCONFIGURATION.
Seems to be a good addition.
> (Btw, would it be possible to use underlines, e.g. COCOON_CONFIGURATION
> to increase readability?)
I guess it's not possible. None of the Apache Jira project keys has
another char than the alphas. This is also true for Spring and Hibernate.
Joerg
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
>
> I don't think that only released blocks will produce JIRA entries. Where
> shall then JIRA entries for unreleased blocks goto? And what happens
> with them when a block is released? Will the be moved into the new
> created JIRA project for the newly released block?
There will be still COCOON project that should be treated both as legacy and sink project. If there
is no suitable JIRA project, create issue at COCOON.
As long as issues will be tied to some component in COCOON project it will be relatively easy to
move all of them to the a created project.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Felix Knecht <fe...@apache.org>.
>> - why separate projects for some blocks? Why exactly these?
>
> I've taken list of modules and blocks released by Reinhard as RC1 and
> collated with this [1] report.
>
> I think that we should create separate JIRA projects for artifacts
> that are already released. Especially if creation of all projects
> would be troublesome (believe me, it's a lot of work).
>
>> - what about the remaining blocks?
>
> As soon as new blocks are released we can call a new vote. I wanted to
> focus on piece doable for me and Joerg (assuming his offer to help is
> still open).
I don't think that only released blocks will produce JIRA entries. Where
shall then JIRA entries for unreleased blocks goto? And what happens
with them when a block is released? Will the be moved into the new
created JIRA project for the newly released block?
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> I don't want to slow down this vote, but looking at the list, I have
> several questions:
I already slowed down it for so long so don't worry ;)
> - why are some modules from cocoon core not listed under cocooncore?
Which ones?
After taking a look at components at this page:
https://issues.apache.org/jira/browse/COCOON
I see that I forgot to mention that all remaining components under Core will be moved to COCOONCORE.
> - why a separate Jira project for the servletservice? and why not for
> others that mind stand on their own?
Servlet service is subproject. I guess you have in mind configurator, right?
If so, I agree with you that it should have its own JIRA project. I just forgot about it.
On the other, this vote is about _dividing_ existing COCOON project. Since there is no corresponding
component for configurator subproject there is nothing to divide. I agree that we should create
separate JIRA project but we should vote it separately, IMO.
> - why separate projects for some blocks? Why exactly these?
I've taken list of modules and blocks released by Reinhard as RC1 and collated with this [1] report.
I think that we should create separate JIRA projects for artifacts that are already released.
Especially if creation of all projects would be troublesome (believe me, it's a lot of work).
> - what about the remaining blocks?
As soon as new blocks are released we can call a new vote. I wanted to focus on piece doable for me
and Joerg (assuming his offer to help is still open).
[1] http://people.apache.org/~gkossakowski/Cocoon%20issues%20from%20last%20120%20days.png
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Carsten Ziegeler <cz...@apache.org>.
I don't want to slow down this vote, but looking at the list, I have
several questions:
- why are some modules from cocoon core not listed under cocooncore?
- why a separate Jira project for the servletservice? and why not for
others that mind stand on their own?
- why separate projects for some blocks? Why exactly these?
- what about the remaining blocks?
Carsten
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
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
Grzegorz Kossakowski wrote:
>
>
> Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer
> plug-in for Eclipse that makes task creation very easy and _natural_.
That wouldn't help me. I use (and advocate) IntelliJ.
Ralph
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke wrote:
> On 20.08.2007 15:08 Uhr, Grzegorz Kossakowski wrote:
>
>> I really wouldn't like to be seen as crazy person blindly pushing us
>> to this split up. To be honest, I would like to do nothing. Such
>> split up is lots of work in JIRA itself, then fixing URLs in our
>> poms, etc. My goal is simple: let our issue tracking have valid
>> information about version particular issue affects and version where
>> particular issue is fixed.
>
> You are not the only person. I'd prefer a better solution as well, but
> I change the camp since it does not seem to be worth the effort at the
> moment. You only move the problem from selecting the right version to
> selecting the right Jira project - and therefore break all the URLs.
> Some like issues linked in Jira comments themselves you can't even fix.
>
> I think in the meantime we should just leave it as is and hope for
> improvements in Jira itself like versions specific to components and
> not only projects.
>
> WDYT?
+1
Ralph
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.08.2007 15:08 Uhr, Grzegorz Kossakowski wrote:
> Let's forget about independent releases. Take a look at COCOON-2091[1]
> issue, it has Fix version set to 2.2. Now if some user would like to
> take advantage of Xinha should start to search Maven repository for
> org.apache.cocoon:cocoon-forms-impl:2.2 right? The answer is: no. It
> should start to search for cocoon-forms-impl:1.0.0-RC2 or
> cocoon-forms-impl:1.0.0. Our 2.2 is almost completely useless because it
> only carries one information: this change does not affect 2.1.x branch,
> nothing more.
This can be easily fixed by adding 1.0 to the list of versions. That's
not really an issue, the actual one is to select the correct version
from a big list.
> I really wouldn't like to be seen as crazy person blindly pushing us to
> this split up. To be honest, I would like to do nothing. Such split up
> is lots of work in JIRA itself, then fixing URLs in our poms, etc. My
> goal is simple: let our issue tracking have valid information about
> version particular issue affects and version where particular issue is
> fixed.
You are not the only person. I'd prefer a better solution as well, but I
change the camp since it does not seem to be worth the effort at the
moment. You only move the problem from selecting the right version to
selecting the right Jira project - and therefore break all the URLs.
Some like issues linked in Jira comments themselves you can't even fix.
I think in the meantime we should just leave it as is and hope for
improvements in Jira itself like versions specific to components and not
only projects.
WDYT?
Joerg
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
Grzegorz Kossakowski wrote:
> Hi Nils,
>
> Nils Kaiser pisze:
>
>> Well, there is even a nicer way to do this. Depending on which
>> edition of JIRA Apache has, you could add a Custom field "Fix Version
>> (Component)" and "Affects Version (Component)". You should be able to
>> do searches and filters on the field then.
>
> Seems like a very nice solution. Using two custom fields "Affects
> Version (Component)" and "Fix Version (Component)" we could give up
> standard JIRA fields as they only cause unnecessary confusion.
>
> How others feel about such solution?
>
>
+1
Ralph
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Grzegorz Kossakowski wrote:
>> Hi Nils,
>>
>> Nils Kaiser pisze:
>>
>>> Well, there is even a nicer way to do this. Depending on which
>>> edition of JIRA Apache has, you could add a Custom field "Fix Version
>>> (Component)" and "Affects Version (Component)". You should be able to
>>> do searches and filters on the field then.
>>
>> Seems like a very nice solution. Using two custom fields "Affects
>> Version (Component)" and "Fix Version (Component)" we could give up
>> standard JIRA fields as they only cause unnecessary confusion.
>>
>> How others feel about such solution?
>
> no objections at all, +1
+1 as well
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Hi Nils,
>
> Nils Kaiser pisze:
>
>> Well, there is even a nicer way to do this. Depending on which edition
>> of JIRA Apache has, you could add a Custom field "Fix Version
>> (Component)" and "Affects Version (Component)". You should be able to
>> do searches and filters on the field then.
>
> Seems like a very nice solution. Using two custom fields "Affects
> Version (Component)" and "Fix Version (Component)" we could give up
> standard JIRA fields as they only cause unnecessary confusion.
>
> How others feel about such solution?
no objections at all, +1
Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Hi Nils,
Nils Kaiser pisze:
> Well, there is even a nicer way to do this. Depending on which edition
> of JIRA Apache has, you could add a Custom field "Fix Version
> (Component)" and "Affects Version (Component)". You should be able to do
> searches and filters on the field then.
Seems like a very nice solution. Using two custom fields "Affects Version (Component)" and "Fix
Version (Component)" we could give up standard JIRA fields as they only cause unnecessary confusion.
How others feel about such solution?
> In fact, I was asking myself of users would provide such detailled
> information anyway when they post a new issue. Even if internally, the
> software is made of components, a user will still download a version in
> the future - on a user's perspective, the bug will be affecting a cocoon
> version and not a component version.
Up to date, when releasing Cocoon 2.2 we were focusing on releasing artifacts and putting them on
Maven repository. Most of the time we assume (or at least advise) Maven is used so user already
needs to deal with Cocoon artifacts' versions in her own pom. Moreover, Maven already provides nice
tools to find out what versions are used so we are likely to ask users this information anyway.
Without exact version of artifact (block) we will not be able to help in most cases, IMO.
All in all, it's not a big deal to ask user to fire mvn project-info-reports:dependencies command.
> So maybe its more in the responsibily of the developers to recognize and
> manage the component version anyway... in that case the custom field
> solution seem to be enough in my opinion.
Or telling user how to provide this information, se above.
> Another remark on the splitted JIRA projects approach: what about issues
> covering more than one component (for example, feature requests)? Or
> where the reporting user does not know which components the error
> belongs to? Or where the components are not existing yet?
>
> In that case it is much easier to correct the information when the
> issues are all in one project where you can add the component(s)
> affected by the issue.
You and others have convinced me that splitting is not such a great idea as I thought previously.
What about this solution?
Anyway, thanks Nils for very useful comments!!
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Nils Kaiser <Ni...@gmx.net>.
Hey Vadim,
Vadim Gritsenko schrieb:
>> The answer is: no. It should start to search for
>> cocoon-forms-impl:1.0.0-RC2 or cocoon-forms-impl:1.0.0.
>
> Open COCOON-2091, remove 'fix version', add comment: 'Fixed in
> cocoon-forms-impl:1.0.0-RC2', done. Personally, I'd not sweat over it
> that much - it's not that big of a deal.
>
> Vadim
Well, there is even a nicer way to do this. Depending on which edition
of JIRA Apache has, you could add a Custom field "Fix Version
(Component)" and "Affects Version (Component)". You should be able to do
searches and filters on the field then.
In fact, I was asking myself of users would provide such detailled
information anyway when they post a new issue. Even if internally, the
software is made of components, a user will still download a version in
the future - on a user's perspective, the bug will be affecting a cocoon
version and not a component version.
So maybe its more in the responsibily of the developers to recognize and
manage the component version anyway... in that case the custom field
solution seem to be enough in my opinion.
Another remark on the splitted JIRA projects approach: what about issues
covering more than one component (for example, feature requests)? Or
where the reporting user does not know which components the error
belongs to? Or where the components are not existing yet?
In that case it is much easier to correct the information when the
issues are all in one project where you can add the component(s)
affected by the issue.
Greetings,
Nils
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Take a look at COCOON-2091[1]
> issue, it has Fix version set to 2.2. Now if some user would like to
> take advantage of Xinha should start to search Maven repository for
> org.apache.cocoon:cocoon-forms-impl:2.2 right?
I'd think he would open up changes log for cocoon-forms block and see where it
was fixes.
Alternatively, he would go to download section of the website and click on
'cocoon-2.2-bin.tar.gz'.
But that's MHO.
> The answer is: no. It
> should start to search for cocoon-forms-impl:1.0.0-RC2 or
> cocoon-forms-impl:1.0.0.
Open COCOON-2091, remove 'fix version', add comment: 'Fixed in
cocoon-forms-impl:1.0.0-RC2', done. Personally, I'd not sweat over it that much
- it's not that big of a deal.
Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Vadim Gritsenko pisze:
> Grzegorz Kossakowski wrote:
>> Vadim Gritsenko pisze:
>>
>> Vadim, I may be biased in favour of JIRA because I use it quite
>> extensively (as you can see yourself) but from my own experience JIRA
>> offers us much more than plain text.
>
> Yes it does but you missed main point - JIRA and independent releases
> are not tied as tight as you think they are.
Let's forget about independent releases. Take a look at COCOON-2091[1] issue, it has Fix version set
to 2.2. Now if some user would like to take advantage of Xinha should start to search Maven
repository for org.apache.cocoon:cocoon-forms-impl:2.2 right? The answer is: no. It should start to
search for cocoon-forms-impl:1.0.0-RC2 or cocoon-forms-impl:1.0.0. Our 2.2 is almost completely
useless because it only carries one information: this change does not affect 2.1.x branch, nothing more.
>> Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer
>> plug-in for Eclipse that makes task creation very easy and _natural_.
>
> I'm IDEA user, Eclipse does not work for me.
>
> As for the subject of the mail - I'm -0 myself: I don't see need to
> split up and I see issues with broken URLs, large and ugly prefixes,
> etc. In short, I see downsides but don't see an upside.
I really wouldn't like to be seen as crazy person blindly pushing us to this split up. To be honest,
I would like to do nothing. Such split up is lots of work in JIRA itself, then fixing URLs in our
poms, etc. My goal is simple: let our issue tracking have valid information about version particular
issue affects and version where particular issue is fixed.
Unfortunately, JIRA does not support versions per component but only per project. My own opinion is
that's rather funny to call product enterprise-ready without this feature (or substitute) especially
that there is huge number of people asking for it.
If we don't go this path, what is another? I think current situation is unacceptable.
> Just trying to give a perspective you haven't considered :)
I have, I'm just out of other ideas...
[1] https://issues.apache.org/jira/browse/COCOON-2091
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Vadim Gritsenko pisze:
>>> I would hazard a guess that impossibility to plan independent
>>> releases in JIRA, assign issues to specific version will be main
>>> cause for failing to do independent releases.
>>
>> We agreed long ago to do more time based releases and less feature
>> based releases. There is no need for Jira to plan time based releases.
>>
>> Moreover, there is also no need for Jira to plan feature based
>> releases as well. You can as easily use status.xml (see todo section)
>> to track features needed for a particular release.
>
> Vadim, I may be biased in favour of JIRA because I use it quite
> extensively (as you can see yourself) but from my own experience JIRA
> offers us much more than plain text.
Yes it does but you missed main point - JIRA and independent releases are not
tied as tight as you think they are.
> Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer
> plug-in for Eclipse that makes task creation very easy and _natural_.
I'm IDEA user, Eclipse does not work for me.
As for the subject of the mail - I'm -0 myself: I don't see need to split up and
I see issues with broken URLs, large and ugly prefixes, etc. In short, I see
downsides but don't see an upside.
>> Don't be. Think of a bright side - status.xml is easier and faster to
>> edit than Jira! :)
>
> :)
> Let it be a joke ;)
Just trying to give a perspective you haven't considered :)
Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Vadim Gritsenko pisze:
>> I would hazard a guess that impossibility to plan independent releases
>> in JIRA, assign issues to specific version will be main cause for
>> failing to do independent releases.
>
> We agreed long ago to do more time based releases and less feature based
> releases. There is no need for Jira to plan time based releases.
>
> Moreover, there is also no need for Jira to plan feature based releases
> as well. You can as easily use status.xml (see todo section) to track
> features needed for a particular release.
Vadim, I may be biased in favour of JIRA because I use it quite extensively (as you can see
yourself) but from my own experience JIRA offers us much more than plain text.
Sorry but I don't really understand if you are joking here but taking your course of argumentation
we could say that version control system is redundant because we can do well with simple bash script
that will make snapshots for us regularly. No need to install svn client, learn its commands, etc.
JIRA offers nice, graphical overview over progress of particular release, can produce release notes
automatically, and so on.
Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that
makes task creation very easy and _natural_.
> Don't be. Think of a bright side - status.xml is easier and faster to
> edit than Jira! :)
:)
Let it be a joke ;)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Vadim Gritsenko <va...@reverycodes.com>.
I feel a need to do some deFUDging here...
Grzegorz Kossakowski wrote:
> On the other hand, current situation is also rather unacceptable because
> our current versions defined in JIRA do mean /nothing/. We all agree we
> need separate (and more often, sight...) release cycles and this *must*
> be expressed in JIRA.
Why? I don't see any relation. Moreover, we can stop using Jira completely and
still merrily do all our releases, with independent release cycles for all
components. Jira does not help nor impede our ability to do so.
> I would hazard a guess that impossibility to plan independent releases
> in JIRA, assign issues to specific version will be main cause for
> failing to do independent releases.
We agreed long ago to do more time based releases and less feature based
releases. There is no need for Jira to plan time based releases.
Moreover, there is also no need for Jira to plan feature based releases as well.
You can as easily use status.xml (see todo section) to track features needed for
a particular release.
> I may speaking about obvious things,
> but possibility to assign bugs to specific versions can improve
> situation both on developer's and user's. We could have a better idea of
> what's need to be done before we can release specific piece of code and
> our users would have a better idea when a specific issue will get fixed
> and how far we are from releasing something.
>
> I'm depressed...
Don't be. Think of a bright side - status.xml is easier and faster to edit than
Jira! :)
Vadim
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Hi Nils,
Nils Kaiser pisze:
> And of course the most voted one was missing:
>
> http://jira.atlassian.com/browse/JRA-846 - Support for subcomponents
> (198 votes)
>
>
> Nils Kaiser schrieb:
>> By following the discussion I had a look wether JIRA people are
>> planning to add some support in that direction and in fact there are
>> some issues related to this:
>>
>> http://jira.atlassian.com/browse/JRA-12241 - Support for Product
>> Suites / Sub-Projects (22 votes)
>> http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to
>> components (18 votes)
>>
>> While this does not add any solution to the problem, you could all
>> vote for the issue or comment it. There are also a lot of duplicates...
Thanks for providing us this info.
The situation looks quite depressing as this issue seems to not going to be addressed in near
future. People's comments already expressed concerns about multiple projects approach. They bloat
Dashboard page and cause management problems because projects that are related when it comes to
functionality and making releases completely lack this information in JIRA. It's exactly an issue
which what Ralph raised[1].
On the other hand, current situation is also rather unacceptable because our current versions
defined in JIRA do mean /nothing/. We all agree we need separate (and more often, sight...) release
cycles and this *must* be expressed in JIRA.
I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to
specific version will be main cause for failing to do independent releases. I may speaking about
obvious things, but possibility to assign bugs to specific versions can improve situation both on
developer's and user's. We could have a better idea of what's need to be done before we can release
specific piece of code and our users would have a better idea when a specific issue will get fixed
and how far we are from releasing something.
I'm depressed...
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74601
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Nils Kaiser <Ni...@gmx.net>.
And of course the most voted one was missing:
http://jira.atlassian.com/browse/JRA-846 - Support for subcomponents
(198 votes)
Nils Kaiser schrieb:
> By following the discussion I had a look wether JIRA people are
> planning to add some support in that direction and in fact there are
> some issues related to this:
>
> http://jira.atlassian.com/browse/JRA-12241 - Support for Product
> Suites / Sub-Projects (22 votes)
> http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to
> components (18 votes)
>
> While this does not add any solution to the problem, you could all
> vote for the issue or comment it. There are also a lot of duplicates...
>
> Greetings,
>
> Nils
>
> Reinhard Poetz schrieb:
>> Grzegorz Kossakowski wrote:
>>> Reinhard Poetz pisze:
>>>> hmmm, the main benefit of having seperate Jira projects is that we
>>>> can have seperate version numbering schemes for each project. But
>>>> looking at e.g. COCOONM2 I don't see how this can be achieved
>>>> because all modules that it contains already have different version
>>>> numbers. If I want to report a bug I don't know which version
>>>> number I have to choose.
>>>
>>> So what can we do? Split into more projects?
>>
>
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Alfred Nathaniel wrote:
> On Sun, 2007-08-19 at 17:44 +0200, Reinhard Poetz wrote:
>> What I mean is that one release cycle should have one Jira project. As soon as
>> we have two modules that have _different_ release cycles and managed by _one_
>> Jira project, I don't understand what we gain compared to the status quo.
>
> Personally, I don't believe that the idea of different release cycles
> will fly for very long. In the end there will be the same sort of
> problems getting a grip on the version compatibilities which made the
> Eclipse people invent the Callisto approach.
>
> And with 100 open JIRA issues, I don't see the necessity of splitting
> into smaller parts. Splitting also assumes that the reporting user is
> able to pinpoint the part where his particular problems stems from. If
> he makes a mistake there, we can correct it by changing the project to
> which it refers -- but that breaks each time the URL.
Talking about large list - you can already filter by component, so no splitting
is necessary to achieve this.
Vadim
> So here's my -0.
>
> Cheers, Alfred.
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Alfred Nathaniel <an...@apache.org>.
On Sun, 2007-08-19 at 17:44 +0200, Reinhard Poetz wrote:
> What I mean is that one release cycle should have one Jira project. As soon as
> we have two modules that have _different_ release cycles and managed by _one_
> Jira project, I don't understand what we gain compared to the status quo.
Personally, I don't believe that the idea of different release cycles
will fly for very long. In the end there will be the same sort of
problems getting a grip on the version compatibilities which made the
Eclipse people invent the Callisto approach.
And with 100 open JIRA issues, I don't see the necessity of splitting
into smaller parts. Splitting also assumes that the reporting user is
able to pinpoint the part where his particular problems stems from. If
he makes a mistake there, we can correct it by changing the project to
which it refers -- but that breaks each time the URL.
So here's my -0.
Cheers, Alfred.
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> I don't want to see Cocoon portal under COCOON_BLOCKS only to have it
> changed later.
>
> I also don't understand the last sentence in Reinhard's email, "IMO we
> should either create them all or don't change anything because I don't
> understand what the benefit of having multiple Jira projects is if we
> can't use correct version numbers.". This implies that separate Jira
> projects can't have correct version numbers, which I don't recall ever
> hearing anything about.
What I mean is that one release cycle should have one Jira project. As soon as
we have two modules that have _different_ release cycles and managed by _one_
Jira project, I don't understand what we gain compared to the status quo.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.08.2007 11:27 Uhr, Ralph Goers wrote:
> I don't want to see Cocoon portal under COCOON_BLOCKS only to have it
> changed later.
This makes me realizing that there will be another drawback: All our bug
references will be broken, e.g. in mails or status.xml. I guess
associating an issue to another project is not a functionality provided
by Jira meaning that COCOON-XYZ gets redirected to COCOON_CORE-ABC
afterwards. It's probably done directly on the database. If that's true
we should avoid to change it too often and need a good first shot - or
avoid it at all and only introduce new Jira projects for new
modules/projects like spring-configurator or servlet-service-framework.
Joerg
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
I don't want to see Cocoon portal under COCOON_BLOCKS only to have it
changed later.
I also don't understand the last sentence in Reinhard's email, "IMO we
should either create them all or don't change anything because I don't
understand what the benefit of having multiple Jira projects is if we
can't use correct version numbers.". This implies that separate Jira
projects can't have correct version numbers, which I don't recall ever
hearing anything about.
I'm not about to vote -1 on this proposal, but I'm also not seeing
others enthusiastically endorsing this either.
Ralph
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> If we can't get this piece of information, I'm +1 for setting up the
>> 20+ projects (http://marc.info/?l=xml-cocoon-dev&m=118728284316195&w=2).
>
> To push this subject forward and do not spoil another vote I would
> like to ask you:
> a) are fine with proposal updated by Reinhard?
> b) are all doubts dispeled so you can vote with confidence?
>
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> If we can't get this piece of information, I'm +1 for setting up the 20+
> projects (http://marc.info/?l=xml-cocoon-dev&m=118728284316195&w=2).
To push this subject forward and do not spoil another vote I would like to ask you:
a) are fine with proposal updated by Reinhard?
b) are all doubts dispeled so you can vote with confidence?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Nils Kaiser wrote:
>> By following the discussion I had a look wether JIRA people are
>> planning to add some support in that direction and in fact there are
>> some issues related to this:
>>
>> http://jira.atlassian.com/browse/JRA-12241 - Support for Product
>> Suites / Sub-Projects (22 votes)
>> http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to
>> components (18 votes)
>>
>> While this does not add any solution to the problem, you could all
>> vote for the issue or comment it. There are also a lot of duplicates...
>
> Thanks Nils for the research. Maybe it's best to wait for these features
> then and only create seperate Jira projects for our two subprojects
> (configuration, servlet-service).
>
> Do the Atlassian folks have some kind of public schedule that gives us a
> clue what they plan for the upcoming releases?
If we can't get this piece of information, I'm +1 for setting up the 20+
projects (http://marc.info/?l=xml-cocoon-dev&m=118728284316195&w=2).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> Thanks Nils for the research. Maybe it's best to wait for these features
> then and only create seperate Jira projects for our two subprojects
> (configuration, servlet-service).
>
> Do the Atlassian folks have some kind of public schedule that gives us a
> clue what they plan for the upcoming releases?
Take a look at[1]. According to comments in these issues, if one is going to be addressed in near
future it's going to have fix version set.
Most of issues reporting demand for this feature are rather old, JRA-846 is five years old... I
would not expect this feature implemented in the future we care of.
[1] http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
Nils Kaiser wrote:
> By following the discussion I had a look wether JIRA people are planning
> to add some support in that direction and in fact there are some issues
> related to this:
>
> http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites
> / Sub-Projects (22 votes)
> http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to
> components (18 votes)
>
> While this does not add any solution to the problem, you could all vote
> for the issue or comment it. There are also a lot of duplicates...
Thanks Nils for the research. Maybe it's best to wait for these features then
and only create seperate Jira projects for our two subprojects (configuration,
servlet-service).
Do the Atlassian folks have some kind of public schedule that gives us a clue
what they plan for the upcoming releases?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Nils Kaiser <Ni...@gmx.net>.
By following the discussion I had a look wether JIRA people are planning
to add some support in that direction and in fact there are some issues
related to this:
http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites
/ Sub-Projects (22 votes)
http://jira.atlassian.com/browse/JRA-3228 - Ability to add versions to
components (18 votes)
While this does not add any solution to the problem, you could all vote
for the issue or comment it. There are also a lot of duplicates...
Greetings,
Nils
Reinhard Poetz schrieb:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>> hmmm, the main benefit of having seperate Jira projects is that we
>>> can have seperate version numbering schemes for each project. But
>>> looking at e.g. COCOONM2 I don't see how this can be achieved
>>> because all modules that it contains already have different version
>>> numbers. If I want to report a bug I don't know which version number
>>> I have to choose.
>>
>> So what can we do? Split into more projects?
>
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> hmmm, the main benefit of having seperate Jira projects is that we can
>> have seperate version numbering schemes for each project. But looking
>> at e.g. COCOONM2 I don't see how this can be achieved because all
>> modules that it contains already have different version numbers. If I
>> want to report a bug I don't know which version number I have to choose.
>
> So what can we do? Split into more projects?
honestly, I don't know what's the best solution for our situation is. Looking at
the latest release we would need following Jira projects:
COCOON_CORE
- org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
- org.apache.cocoon:cocoon-util:1.0.0-RC1
- org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
- org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
- org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
- org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
- org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
- org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
- org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
- org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
- org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
- org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
- org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
- org.apache.cocoon:cocoon-core:2.2.0-RC1
COCOON_SERVLETSERVICE
- org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
- org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2
COCOON_FORMS
- org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
COCOON_TEMPLATE
- org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
COCOON_APPLES
- org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
COCOON_LINKREWRITE
- org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
COCOON_AUTH
- org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
- org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
COCOON_BATIK
- org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
COCOON_CAPTCHA
- org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
COCOON_DATABASE
- org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
- org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
COCOON_HSQLDB
- org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
- org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
COCOON_FLOWSCRIPT
- org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
COCOON_FOP
- org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
COCOON_HTML
- org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
COCOON_MAIL
- org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1
COCOON_FORMS
- org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
COCOON_AJAX
- org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3
COCOON_M2
- org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
- org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
- org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1
COCOON_M2_ARCHETYPES
- org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
- org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
- org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1 #
COCOON_CONFIGURATION
- org.apache.cocoon:cocoon-configuration-api:1.0.0
- org.apache.cocoon:spring-configurator:1.0.0
COCOON_BLOCKS
-> the rest of the issues which belong to a block that hasn't it's
own Jira project yet because it is not ready to be released.
These are ~20 Jira projects. IMO we should either create them all or don't
change anything because I don't understand what the benefit of having multiple
Jira projects is if we can't use correct version numbers.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> hmmm, the main benefit of having seperate Jira projects is that we can
> have seperate version numbering schemes for each project. But looking at
> e.g. COCOONM2 I don't see how this can be achieved because all modules
> that it contains already have different version numbers. If I want to
> report a bug I don't know which version number I have to choose.
So what can we do? Split into more projects?
> Apart fromt that I miss COCOONCONFIGURATION. (Btw, would it be possible
> to use underlines, e.g. COCOON_CONFIGURATION to increase readability?)
According to http://www.atlassian.com/software/jira/docs/latest/project_keys.html#Project+Key+Pattern
it's configurable so we would have to ask infra for configuration details on Apache.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Reinhard Poetz <re...@apache.org>.
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
hmmm, the main benefit of having seperate Jira projects is that we can have
seperate version numbering schemes for each project. But looking at e.g.
COCOONM2 I don't see how this can be achieved because all modules that it
contains already have different version numbers. If I want to report a bug I
don't know which version number I have to choose.
Apart fromt that I miss COCOONCONFIGURATION. (Btw, would it be possible to use
underlines, e.g. COCOON_CONFIGURATION to increase readability?)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [VOTE] Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
>