cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: on better release and version management
Date Tue, 23 Sep 2003 12:21:26 GMT

On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:

> A few days ago someone mentione something about "individually
> releasable units". I personally think this might be the way to go, peep
> over to Avalon land and see how they manage it.
> By individually releasable units (IRU) I can see the following:
> - The Core.
>     My undestanding of the Cocoon core starts at the o.a.c.Cocoon class
>     and doesn't go into any implementation of some contracts
>     (interfaces) it uses. Admittedly, such an implementation wouldn't
>     run by itself because important part are missing, but please read
>     ahead.
> - Cocoon core API (set of interfaces)
>     We do have abstracted alot in cocoon to have the possibility to
>     create core part by more than just one implementation like
>     TreeProcessor vs. compiled sitemap, or JavascriptFlow vs.
>     SchemeFlow vs. JavaFlow (the later one was just a discussion not a
>     real implementation, but you get what I mean). This of course is 
> the
>     basic set of interfaces for the Core.
> - Each implementation of the Contract mentioned above could make it 
> into
>   a IRU because some people want the TreeProcessor other the "compiled
>   sitemap" implementation but rarely both.
> - Cocoon Environment API
>     The abstration of this part also manifests im different
>     implementation we have so far (CLI, Servlet, Bean).
> - Again, each implementaion of the Environment API above could make a
>   IRU. And also for some use cases the one or the other is suitable
>   (Forrest will prefer the CLI environment, most of us the Servlet one,
>   etc.)
> - Block API
>     IIUC the blocks we're discussing intensively these days need a 
> solid
>     base so block developpers can start building upon. Probably all the
>     rest of the interface we have will fall into this category (ie.
>     all SitemapComponents etc.)
> - A Block implementation
>     Each block implementation will be a IRU of course. It has for
>     sure it's own development cycle.
> This of course are my personal oppinios about a better version
> management, release management and resource management. It'll break
> apart the monilitic release process we have today and allows much more
> flexibility and also more compact composition of a Cocoon System.
> The drawback is that we need another system to compose (as we have 
> today
> with the local.* files) a running core system: The real core, core
> implemetations of abstracted parts, environment implementaion and the
> core block implementation (I'm thinking of the BlockDeployerBlock which
> was mentioned by someone)
> What do you think about this?

I agree with you that even a 'naked cocoon' (a cocoon with no 
functional blocks) can be further modularized, even if I personally 
don't resonate with the modularization that you propose above.

I think that we should *NOT* try to bite more than we can chew for 2.2, 
let's avoid doing everything in one huge step or this will take us 
another 18 months to release 2.2 and this is going to hurt us badly.

I would simply suggest to:

  1) start cocoon-2.2 with code and existing build system. No blocks, no 

  2) remove fake block machinery from the build system of 2.2

  3) implements real block in 2.2

  4) see what happens next


View raw message