Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Wed, 24 Sep 2003 15:41:30 +0200 (CEST)
From: Giacomo Pati <giacomo@apache.org>
Sender: giacomo@lapgp.otego.com
To: dev@cocoon.apache.org
Subject: Re: on better release and version management
In-Reply-To: <A4A8046D-EE7C-11D7-AD24-000393D2CB02@apache.org>
Message-ID: <Pine.LNX.4.53.0309241512180.2653@lapgp.otego.com>
References: <A4A8046D-EE7C-11D7-AD24-000393D2CB02@apache.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.

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).

> > 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 http://maven.apache.org or
http://www.krysalis.org/centipede/

> 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.
  - 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)
  - 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).

>
> just don't know why we should modularize that much, that's all.
>
> >> 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.
> >
> > ET ;-)
> >
> >> I would simply suggest to:
> >>
> >>   1) start cocoon-2.2 with code and existing build system. No blocks,
> >> no
> >> documentation.
> >
> > If you suggest starting with just more or less core code why not move
> > to
> > another build system we can build a modularized system upon?
>
> but what do we gain? [I'm not caustic, just curious]

Easier modularisation capabilities.

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com