cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Division of Cocoon's JIRA project
Date Fri, 29 Jun 2007 10:12:29 GMT
Jeff Turner pisze:
> Hi,
> On Wed, Jun 27, 2007 at 01:14:33AM +0200, Grzegorz Kossakowski wrote:
>> Hello,
>> At Apache Cocoon development mailing list we are currently discussing[1] 
>> division of Cocoon's JIRA project. There are two reasons for a such move:
>> 1. We are starting to release smaller parts more independently so we need 
>> different version sets
> I don't think splitting the COCOON project is a good idea..
> From what I see, you've arbitrarily divided Cocoon modules into areas of
> functionality ("core", "database", "forms" etc) and want a separate
> project for each. From a JIRA modelling POV, the only advantage of
> splitting these into separate projects is so each can have their own
> versions, components and release process (release notes, etc).

In Apache Cocoon we have concept called "block". It is a self-containing package (JAR file)
which extends Cocoon functionality to almost any 
extend. To not discuss details think of block as a plug-in. We have been having a Cocoon's
source code divided into blocks for years. Only 
now, thanks to Maven we have a necessary infrastructure to release and deliver these blocks

Our main motivation for having separate projects is that we really need independent versioning.

> Are you actually going to rev each part independently? Will you be making
> public announcements like "Today Cocoon forms advanced to v1.2.3"?  Will
> users normally update their Cocoon Forms without also upgrading the Core?

Yes, and yes.

> Ie., are these actually separate modules from the _user's_ point of view,
> rather than the developers'?  When searching for bugs, will users think
> to search across all relevant projects? Will they know what project to
> file new bugs in?

I think, yes. Every block has it's own Java package and focuses clearly on some functionality
so usually users will now to which project the 
problem/bug belongs.

Have a look at our (unpublished yet) docs:
We already have a very clear separation of each part, only JIRA separation is lacking now.

> Apart from versioning, are there any other fields common to each
> 'project' that JIRA's current organization prevents you having?

Versioning is most important, the same goes for release notes etc.

>> 2. One big project is simply too big
> "too big" meaning? There are plenty of larger or comparably sized
> projects in JIRA:

I'm not sure about projects mentioned below but what about componenets? We have plenty of
them and I guess we would have to double the 
number of them to cover all Cocoon's corners.

> jira_391=> select pkey, pcounter from project order by pcounter desc;
>    pkey   | pcounter 
> ----------+----------
>  HARMONY  |     4300
>  GERONIMO |     3272
>  DERBY    |     2882
>  AXIS2    |     2876
>  AXIS     |     2677
>  XALANJ   |     2386
>  COCOON   |     2080
>> One issue, raised[2] by Joerg Heinicke is if proposed JIRA keys should be 
>> somehow put into Cocoon context by e.g. prefixing them with 'C' letter.
>> What's your opinion on this issue? Are you fine with keys originally 
>> proposed?
> Splitting projects clutters the dashboard and project lists. At least
> prefix each split project name with something meaningful ("COCOONCORE",

Some keys will become really long, isn't 'C' enough as a prefix?

> The only technical problem is that JIRA's bulk move will lose any version
> and component information when moving between projects (that's what's
> currently holding up the ADFFACES -> TUSCANY rename).

Can't we run bulk move for each version separately? When it comes to component information
it's not that important, we would have to 
restructure significantly anyway.

> In summary, I don't think this makes sense from a JIRA modelling point of
> view or a Cocoon users point of view, and it will just clutter JIRA for
> everyone else. But then perhaps I'm just not understanding the
> motivation. If Cocoon developers want to go ahead, my only caveat is that
> project keys should be prefixed with "COCOON" to save everyone else
> confusion.

As explained earlier we are really leaning towards independent releases. There are part in
Cocoon that will probably grow rapidly (servlet 
service fw) and will demand lots of releases and parts that are quite stable and will be released
at slower peace. Mixing such parts is not 
convenient for us.

Grzegorz Kossakowski

View raw message