Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Cocoon undergo phase transition when moving from 1.x to 2.x.
Are we doing it again?
The question on the table is: we *NEED* better class discovery and classloading isolation. This is a must, just like the need for SAX pipelines drove 2.x away from 1.x in a non-incremental way (phase transition, as I said).
Can we implement classloading isolation with incrementally modifying what we already have?
From the descriptions sent by Ugo and Sylvain, they both agree that "kernel container" is something completely different than "intra-block container", which means that it should be implemented on top of existing Cocoon codebase as loader and manager of intra-containers regardless of particular technology used for implement intra-container (ECM, Spring, shell script...)
So me feeling here is that these are two separate threads; * Steps to implement "kernel container". Pier made the first step already. * Directions for improvement "intra container". One decision we made recently was (finish) the move to Fortress.
We can back up from that commitment and choose different target, be it Nano/Pico/Merlin/etc, but it should be independent of kernel container, so we can do that in parallel tracks.
And one more discussion thread is needed, about roadmap for 2.1 branch, 2.2 branch, and possibly 2.3. Cocoon 2.2 is a good place to introduce fortress, and Cocoon 2.3 can have other intra-container implementations, whatever we choose.
Vadim, let me be crystal clear: I DO NOT want to depend on fortress!
I've been trying to get that fucking thing working and it depends on things that Berin has on d-haven.org and only *HE* maintains.
We didn't want Merlin because it was a one man show, but Fortress is way more of a one man show that Merlin is (at least Merlin compiles in gump, <shrug/>)
I have great respect for the people involved, but they are not a community, they are a bunch of avalon refugees and that's the only thing that unifies them.
Depending more on avalon/merlin/excalibur will just hurt us more.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
