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/06/22 18:14:05 UTC
Separate projects on JIRA - final proposal
Hello,
Reinhard asked[1] me to provide a final list of Cocoon modules that would get their own JIRA projects. Here is 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
- Servlet service framework (SERVLETSERVICE)
* org.apache.cocoon:cocoon-servlet-service-components
* org.apache.cocoon:cocoon-servlet-service-impl
* org.apache.cocoon:cocoon-servlet-service-sample
- Template (TEMPLATE)
* org.apache.cocoon:cocoon-template-impl
* org.apache.cocoon:cocoon-template-sample
- Flowscript (FLOWSCRIPT)
* org.apache.cocoon:cocoon-flowscript-impl
- Database (DATABASE)
* 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 (FORMS)
* 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
The main idea is to split up current big COCOON JIRA project into smaller projects focused on one area. Artifacts that are not listed above
would stay in COCOON project, at least for now. I don't want to create new separate projects for every artifact/block because big number of
project in JIRA would not improve maintenance, quite contrary I would say. After taking this first step towards separation we should just
wait and see if further divisions are needed.
Each artifact belonging to JIRA project would become its component. That means we still have to have shared version number in JIRA's
projects (e.g. in COCOONCORE where cocoon-core is 2.0.0 and sitemap-impl is 1.0.0) but I think its compromise between situation we have
today and a situation where we have about fifty different JIRA projects that no one wants to force her way through.
If we agree on the proposal I would take care of labour work, like asking JIRA for projects creation, moving issues, adjusting poms etc.,
myself during next weekend. What do you think?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Separate projects on JIRA - final proposal
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Ralph Goers pisze:
>
>
> I would expect to also see Portal in this list.
I focused my attention on artifacts that are released (or are going to be released very soon). I do want to limit the work (so number of
projects) to be able to handle whole process during the incoming weekend.
I would be happy to create JIRA project for Portal as soon as it gets released.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Separate projects on JIRA - final proposal
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> Grzegorz Kossakowski wrote:
>> Hello,
>>
>> Reinhard asked[1] me to provide a final list of Cocoon modules that
>> would get their own JIRA projects. Here is 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
>> - Servlet service framework (SERVLETSERVICE)
>> * org.apache.cocoon:cocoon-servlet-service-components
>> * org.apache.cocoon:cocoon-servlet-service-impl
>> * org.apache.cocoon:cocoon-servlet-service-sample
>> - Template (TEMPLATE)
>> * org.apache.cocoon:cocoon-template-impl
>> * org.apache.cocoon:cocoon-template-sample
>> - Flowscript (FLOWSCRIPT)
>> * org.apache.cocoon:cocoon-flowscript-impl
>> - Database (DATABASE)
>> * 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 (FORMS)
>> * 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
>>
>> The main idea is to split up current big COCOON JIRA project into
>> smaller projects focused on one area. Artifacts that are not listed
>> above would stay in COCOON project, at least for now. I don't want to
>> create new separate projects for every artifact/block because big
>> number of project in JIRA would not improve maintenance, quite
>> contrary I would say. After taking this first step towards separation
>> we should just wait and see if further divisions are needed.
I would expect to also see Portal in this list.
Re: Separate projects on JIRA - final proposal
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Grzegorz Kossakowski wrote:
>
> <snip/>
>
>>
>>> If we agree on the proposal I would take care of labour work, like
>>> asking JIRA for projects creation, moving issues, adjusting poms
>>> etc., myself during next weekend. What do you think?
>>
>> Do you ask for a seperate JIRA instance or new projects only?
>
> I think that having new projects will be sufficient. Do you know any
> advantages of having separate JIRA instance?
No, I don't think so.
> Repeating the question: shall I start a vote after clarifying the issues
> above?
Please do!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Separate projects on JIRA - final proposal
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Grzegorz Kossakowski wrote:
<snip/>
>
>> If we agree on the proposal I would take care of labour work, like
>> asking JIRA for projects creation, moving issues, adjusting poms etc.,
>> myself during next weekend. What do you think?
>
> Do you ask for a seperate JIRA instance or new projects only?
I think that having new projects will be sufficient. Do you know any advantages of having separate JIRA instance?
Repeating the question: shall I start a vote after clarifying the issues above?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Separate projects on JIRA - final proposal
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Hello,
>
> Reinhard asked[1] me to provide a final list of Cocoon modules that
> would get their own JIRA projects. Here is 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
> - Servlet service framework (SERVLETSERVICE)
> * org.apache.cocoon:cocoon-servlet-service-components
> * org.apache.cocoon:cocoon-servlet-service-impl
> * org.apache.cocoon:cocoon-servlet-service-sample
> - Template (TEMPLATE)
> * org.apache.cocoon:cocoon-template-impl
> * org.apache.cocoon:cocoon-template-sample
> - Flowscript (FLOWSCRIPT)
> * org.apache.cocoon:cocoon-flowscript-impl
> - Database (DATABASE)
> * 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 (FORMS)
> * 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
>
> The main idea is to split up current big COCOON JIRA project into
> smaller projects focused on one area. Artifacts that are not listed
> above would stay in COCOON project, at least for now. I don't want to
> create new separate projects for every artifact/block because big number
> of project in JIRA would not improve maintenance, quite contrary I would
> say. After taking this first step towards separation we should just wait
> and see if further divisions are needed.
sounds good
> Each artifact belonging to JIRA project would become its component.
makes sense
> That
> means we still have to have shared version number in JIRA's projects
> (e.g. in COCOONCORE where cocoon-core is 2.0.0 and sitemap-impl is
> 1.0.0) but I think its compromise between situation we have today and a
> situation where we have about fifty different JIRA projects that no one
> wants to force her way through.
that's no problem to have shared version numbers in the proposed projects AFAICT
> If we agree on the proposal I would take care of labour work, like
> asking JIRA for projects creation, moving issues, adjusting poms etc.,
> myself during next weekend. What do you think?
Do you ask for a seperate JIRA instance or new projects only?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Separate projects on JIRA - final proposal
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> I don't insist on it at all, just wanted to mention it.
Sorry, bad wording.
> Best is probably indeed to ask infra.
Already done it, waiting for responses.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Separate projects on JIRA - final proposal
Posted by Joerg Heinicke <jo...@gmx.de>.
Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
> I was concerned about identifiers too.
>
> but if you insists on this I'm fine to tweak the proposal.
>
> Meanwhile, I ask infra people for their opinion on this subject.
I don't insist on it at all, just wanted to mention it. Best is probably indeed
to ask infra.
Joerg
Re: Separate projects on JIRA - final proposal
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 22.06.2007 18:14, Grzegorz Kossakowski wrote:
>
>> - Cocoon Core (COCOONCORE)
>> - Servlet service framework (SERVLETSERVICE)
>> - Template (TEMPLATE)
>> - Flowscript (FLOWSCRIPT)
>> - Database (DATABASE)
>> - Forms (FORMS)
>> - M2 Plugins and archetypes (COCOONM2)
>
> Are these the final names on the same level as COCOON is now? IMO names
> like TEMPLATE, DATABASE and FORMS are rather common, maybe even
> FLOWSCRIPT. Shouldn't they be put into a more Cocoon context? CFORMS and
> CTEMPLATE were at least our development names though not the brands we
> want to have them.
I was concerned about identifiers too. Looking at https://issues.apache.org/jira/secure/Dashboard.jspa we can see that there is no policy.
Some projects are put in context (by prefixing with a letter) others not. I'm not sure if it's crucial to have 'C' letter before every
identifier but if you insists on this I'm fine to tweak the proposal.
Meanwhile, I ask infra people for their opinion on this subject.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Separate projects on JIRA - final proposal
Posted by Joerg Heinicke <jo...@gmx.de>.
On 22.06.2007 18:14, Grzegorz Kossakowski wrote:
> - Cocoon Core (COCOONCORE)
> - Servlet service framework (SERVLETSERVICE)
> - Template (TEMPLATE)
> - Flowscript (FLOWSCRIPT)
> - Database (DATABASE)
> - Forms (FORMS)
> - M2 Plugins and archetypes (COCOONM2)
Are these the final names on the same level as COCOON is now? IMO names
like TEMPLATE, DATABASE and FORMS are rather common, maybe even
FLOWSCRIPT. Shouldn't they be put into a more Cocoon context? CFORMS and
CTEMPLATE were at least our development names though not the brands we
want to have them.
Joerg
Re: Separate projects on JIRA - final proposal
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>> I think it makes sense to have an own jira project for the
>> configurator stuff as well.
>
> You are right, configurator is already released and it's worth having
> own JIRA project for sure. I only wonder what JIRA identifier pick for
> configurator (or configuration?) stuff. CONFIGURATION is already taken
> by Commons configuration, so what options do we have?
> Are you fine with COCOONCONFIG?
>
Yes, sounds good - if there is no length limit I would prefer
COCOONCONFIGURATOR, but COCOONCONFIG is ok as well.
Carsten
Re: Separate projects on JIRA - final proposal
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> I think it makes sense to have an own jira project for the configurator
> stuff as well.
You are right, configurator is already released and it's worth having own JIRA project for sure. I only wonder what JIRA identifier pick for
configurator (or configuration?) stuff. CONFIGURATION is already taken by Commons configuration, so what options do we have?
Are you fine with COCOONCONFIG?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Separate projects on JIRA - final proposal
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski schrieb:
> Hello,
>
> Reinhard asked[1] me to provide a final list of Cocoon modules that
> would get their own JIRA projects. Here is 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
> - Servlet service framework (SERVLETSERVICE)
> * org.apache.cocoon:cocoon-servlet-service-components
> * org.apache.cocoon:cocoon-servlet-service-impl
> * org.apache.cocoon:cocoon-servlet-service-sample
> - Template (TEMPLATE)
> * org.apache.cocoon:cocoon-template-impl
> * org.apache.cocoon:cocoon-template-sample
> - Flowscript (FLOWSCRIPT)
> * org.apache.cocoon:cocoon-flowscript-impl
> - Database (DATABASE)
> * 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 (FORMS)
> * 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
>
> The main idea is to split up current big COCOON JIRA project into
> smaller projects focused on one area. Artifacts that are not listed
> above would stay in COCOON project, at least for now. I don't want to
> create new separate projects for every artifact/block because big number
> of project in JIRA would not improve maintenance, quite contrary I would
> say. After taking this first step towards separation we should just wait
> and see if further divisions are needed.
>
> Each artifact belonging to JIRA project would become its component. That
> means we still have to have shared version number in JIRA's projects
> (e.g. in COCOONCORE where cocoon-core is 2.0.0 and sitemap-impl is
> 1.0.0) but I think its compromise between situation we have today and a
> situation where we have about fifty different JIRA projects that no one
> wants to force her way through.
>
> If we agree on the proposal I would take care of labour work, like
> asking JIRA for projects creation, moving issues, adjusting poms etc.,
> myself during next weekend. What do you think?
>
I think it makes sense to have an own jira project for the configurator
stuff as well.
Carsten