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 documentation.
2) remove fake block machinery from the build system of 2.2
3) implements real block in 2.2
4) see what happens next
-- Stefano.
