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 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.
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).
hmmmm
I would strongly suggest to wait to refactor the build system until we are finished implementing the block architecture.... let's work incrementally.
At that point, we'll see what we can improve on what we have.
--Stefano.
