Carsten Ziegeler wrote:
Daniel Fagerstrom schrieb:
We should only use externals to projects with own release cycles. The
idea of breaking out the blocks from trunk was to start considering them
as separate projects with separate release cycles.
Yeah, agreed - but this doesn't work for 2.1.x wrt forms. So when doing
the release, the release manager has take care of this. Sigh :)
So let's stop doing releases on 2.1.x! (only kidding (partly)).
The when we do a "compound" release of Cocoon core together with all
blocks, all the externals in the taged compound release should point to
tagged releases of the blocks.
This certainly isn't our current practice. But I think we need to start
considering the blocks like separate projects sooner rather than later.
Its time that we stop thinking about Cocoon as one huge beast where
everything is connected to everything else. First it isn't, and second
it doesn't scale at all.
Big +1, I said it several times and just for the record I repeat it:
let's remove all blocks from 2.2 now and start treat them as separate
projects. We will never come to a build system for real blocks if we
still treat Cocoon as one monolithic block.
Yup. I'm game. But we need some kind of interim build process don't we?
We've still got the maven pom.xml that lists all of the blocks - I
presume we want to reverse this - have the blocks refer to Cocoon rather
than Cocoon refer to the blocks.
So, an Ant target that looks for src/blocks/*/trunk/pom.xml or
${external-blocks}/*/trunk/pom.xml, builds it and installs it into the
webapp would be very useful, until we've got better deployment tools.
Thinking more about it: with the wild card includes for configurations
and sitemaps, is there still anything that prevent us from having binary
releases?
Patching web.xml is the only thing which comes to my mind. The patching
is need for
some rare blocks that add own servlets or servlet filters to web.xml.
Apart from that, I think nothing prevents us.
As I say, pom.xml currently refers to all blocks.
Also, gump.xml refers to all blocks. Presumably we could have
http://svn.apache.org/repos/asf/cocoon/blocks/gump.xml which points to
all of the gump.xml's for each of our blocks - somewhere we'll have to
tell Gump what we do.
I'm trying to create myself a block at the moment in 2.2, so this is
very relevant.
Regards, Upayavira
