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 Wed, 24 Sep 2003 15:03:11 GMT

On Wednesday, Sep 24, 2003, at 15:41 Europe/Rome, Giacomo Pati wrote:

> On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
>> On Tuesday, Sep 23, 2003, at 19:41 Europe/Rome, Giacomo Pati wrote:
>>> On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
>>>> On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
>>> <SNIP/>
>>>> 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.
>>> Could you explain why you don't resonate? Is it that you fear
>>> complexity?
>>  From what you outlined, it seems unnecessarely complex to separate
>> cocoon in so many parts. But maybe you are proposing a solution for a
>> problem that I don't see.
> Is it the intention to deploy different implementation of stuff you'd
> only need one (or could configure only one) in your cocoon server
> (TreeProcessor vs. "compile sitemap", JavascritpFlow vs. others)? That
> was my thinking. It is not the same with SitemapComponents of course.

While I think that modularization of the cocoon core might make sense 
in the future, I think we do not have enough knowledge about that just 
yet, also because modularization of the core might well require some 
refactoring (for example, in order to remove the instrumentation).

> As a linux guy I know the 'make xconfig' to configure a kernel and I
> could imagine that such a GUI could come in handly for our users as
> long as we don't ship binares (yes, users like to click and jelly-swing
> comes to my mind).

but you are making a pretty wrong assumption here: we don't ship 
binaries with 2.1, but we *WILL* ship binaries with 2.2 as all 
build-time action was required for blocks and now will be dealt with by 
the block deployer (running outside) /block manager (running inside 
cocoon) couple at run time.

while I agree that a naked cocoon might require modularization, I'm not 
sure I want to deal with this just yet. [let's not put too many irons 
in the fire!!]

>>> We're used to Centipede and Maven for some project we've done 
>>> recently
>>> and our experience is that indeed a modularisation as I've proposed 
>>> is
>>> quite complex with bare Ant as building tool but tools like Maven and
>>> Centipede are very helpfull for these kinda projects. We just need to
>>> make the step beyond Ant.
>> I'm in favor of having an easy to manage build system... but probably
>> since I never used anything else but ant I'm don't know what I'd gain
>> since I'm fine with the build system we have (which I wrote, so I'm
>> admittedly biased).
> I'm not going to tell you the story about Centipede/Maven but maybe
> you find some time to have a look at or

>> But if anybody wants to show me the light, I'll be glad to learn
>> something new ;-)
> The main part for me is
>   - lots of predefined targets/goals to use (compile, package,
>     test, dist, etc.) which of course can be parametrized or extended.

we already have those, don't we?

>   - no need to have any jars in the CVS repository anymore or at least
>     only some exotic ones that are not distributed over the web (today
>     more than 40% of the cocoon cvs space is needed by jars and this is
>     even more in our zipped distributions)

this is a good point.

>   - have multiple sub project in the repository which will be build all
>     the same way with only one project.xml descriptor for name, 
> version,
>     etc. per sub project (this is Maven specific).


I would strongly suggest to wait to refactor the build system until we 
are finished implementing the block architecture.... let's work 

At that point, we'll see what we can improve on what we have.

> --

View raw message