cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Date Wed, 26 Feb 2003 18:39:07 GMT
Leo Simons wrote:
> Stefano Mazzocchi wrote:
>> Recently on avalon-dev I expressed my concerns about their habit of 
>> moving stuff around for elegance-sake, but I'm starting to think that 
>> Cocoon is abusing avalon and this places too much pressure on their 
>> shoulders.
> ah, the load, the load! I can't take it anymore!!!!
> <action type="jump-of-cliff" entity="avalon"/>
> AAAAAaaaaaa a a  a   a    h!
> :D:D Just kiddin' :D

LOL :)

>> Example: the instrumentation. The Cocoon core is based on code that 
>> has never been released. So, Avalon has the right to move it around 
>> (and screw us). But I don't think it's *their* fault, it's entirely ours.
> I don't really care who's to blame, there's just an issue needing 
> fixing...though I support the search for the right policy :D


> If people that know both cocoon and avalon well can figure out what 
> stuff in avalon it is that cocoon _really_ needs atm, and we can figure 
> out what it takes to get that released, and then do it (already working 
> on it, all help welcome :D), that pretty much make the world happier :D. 
> Berin's list of a few days ago:
> Collections
> Concurrent
> i18n
> instrument
> instrument-manager
> instrument-manager-interfaces
> IO
> Logger
> Monitor
> Naming
> Pool
> SourceResolve
> Store
> XMLUtil
> Cornerstone
> Cornerstone-excalibur-thread
> Cornerstone-excalibur-threadcontext
> DataSource
> AltRMI
> AltRMI Registry
> AltRMI Server (IMpl/Interfaces)
> Component (AKA ECM)
> (AltRMI is no longer part of avalon though; that's in incubator now)
> Of this list, if it is possible and sensible to remove the cocoon deps on
> cli,
> collections,
> concurrent,
> IO,
> "all of cornerstone" (as opposed to one or two specific blocks) and
> AltRMI,
> I recommend y'all try. 

I have to be honest with you: I find the dependency on tons of small 
jars disturbing to say the least. I know it's probably possible to move 
from excalibur-cli to commons-cli or whatever, but I don't know how, 
nor, to be honest, I even dare to touch it. And this is just an example.

I know Avalon Framework, but almost everything else looks mysterious and 
incredibly fragmented to my eyes.

I'm not asking for migration docs or anything, I'm just stating that I 
find it irritating to have so many dependencies and not even have a way 
to find out what depends on what.

> You may also want to drop your deps on 
> instrument-manager (IMV, instrumentation management should be plugged 
> into the container (ECM), and client code like cocoon shouldn't have to 
> deal with it). Note this is just recommendations on personal title, no 
> consensus within avalon (yet) about everything on that list.

Which is adding concerns over concerns.

> If there's stuff missing from this list, it'd be good to know.
> I think it is a good idea to get the gump descriptors for cocoon and 
> avalon (further) in sync with reality so this information is 
> machine-readable and auto-maintained :D

No shit. Another thing that looks mysterious to me is Gump so any help 
will be very appreciated.

> cheers,
> - Leo
> PS: please CC dev@avalon on the avalon deps in cocoon; there's certainly 
> willingness to help out with this stuff over @ avalon but I can't keep 
> up with your massive amount of traffic :D


Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message