cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [design] Cocoon Blocks 1.1
Date Thu, 07 Nov 2002 23:22:57 GMT
Hi,

On Fri, 8 Nov 2002 00:12, Stefano Mazzocchi wrote:
> > 	I agree, ECM isn't powerful enough to handle all this. The 2 new
> > 	Avalon containers are Fortress and Merlin.
> >
> > 	It would be great if there was some synergy between Avalon & Cocoon
> > 	to develop/improve one/both of these containers to be suitable for
> > 	use in Cocoon, rather than implement our own.
>
> I think everybody agrees here. I also think it would be great to count
> also Phoenix into that, althought I'm not sure on the issues there.
> Peter, what do you think?

Phoenix is not really appropriate in its current form - neither is any of the 
other containers unfortunately. There is a lot of code that can be reused 
directly and a lot knowledge that can be mined from avalon - however besides 
some of the utility toolkits there is not much else :) 

I ran into almost exactly the same issues when I was active on the Ant 
proposal. Funnily enough it almost has identical requirements as Cocoon from 
a container.

Anyways I have a sort of old document that describes different approachs and 
tradeoffs. I will forrestize it and send it to you. From memory it basically 
describes things like;

* differences between deployable units (think .wars) and reusable units (think 
.jars)
* Why you should use the Extension/Optional Package specification to define 
packages, versioning, dependency evaluation etc.
* Different approaches for classloader construction (cloned trees for each 
"inheritance" tree).
* How to cascade resource lookup (sorta of related to inheritance aswell)
* layout of archives
* descriptor partioning and structure
* installing vs deploying deployable units
* metadata definitions and how to actually get them used by developers
etc.

There is also a bunch of utility code that is being built at the moment to 
handle this sort of stuff. A lot of it is being cleaned, unit tested and 
moved back into Excalibur from Phoenix (though it will probably end up at 
Commons@Apache). Theres other stuff that is under development that would also 
be useful.

Anyways I will see if I can get that doc and send it on.

> Easy here. The difference between Avalon and Cocoon is that Cocoon has a
> bigger and more focused community. Avalon framework is great. But
> everything else, well, it's fragmented like hell. It's mostly a tons of
> one-man shows. I hate that.

agreed. ;(

> Until this situations remains, I don't feel confortable with moving more
> stuff over to Avalon even if this makes sense architecturally.

Move it to Commons@Apache when it goes live ! ;)

-- 
Cheers,

Peter Donald
He strains to hear a whisper who refuses to hear a shout.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message