On Fri, 19 Sep 2003, Sylvain Wallez wrote:
> Steven Noels wrote:
>
> > Carsten Ziegeler wrote:
> >
> > <snip type="happy agreement"/>
<even-more-snipped/>
> Let me try to make a synthesis and proposal :
>
> 1 - creating a 2.2 repository is necessary to start working while still
> be able to issue 2.1.x maintainance releases,
This is just a physical working necessity, right?
> 2 - copying all blocks to the 2.2 repo is not wanted since not all
> blocks will evolve in the 2.2
I think we have to clean up the build process from bottom again (see
below).
> 3 - the "real blocks" may require some modifications of the current
> "fake blocks".
>
> So what about the following (somewhat already expressed, BTW) :
> - start a 2.2 repo with only the Cocoon core (i.e. src/java)
> - copy blocks in the 2.2 repo only if they require substantial changes
> that would break the ability to quickly do a 2.1.x release.
> - have an intelligent 2.2 build that gets missing blocks from the 2.1
> (IIRC Carsten talked about it)
> - backport to the 2.1 non disruptive enhancements/bug fixes appearing in
> the 2.2 repo
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?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
