cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [GUMP] Good news and bad
Date Sat, 15 Mar 2003 12:43:08 GMT
Berin Loritsch wrote:

>>> Now, more good news:
>>>
>>> On March 18, 2003 Avalon will be releasing a new set of Excalibur
>>> components (as part of our continuing effort stated above).  You will
>>> have a new version of ECM and its dependencies.  ECM now has a
>>> "big jar" option which merges ECM's Avalon dependencies into one
>>> JAR file.  This will be part of the release.  As a result, you can
>>> get rid of a few jars in CVS and replace it with one.
>>
>>
>>
>> Hmmm, this would force us to update the jar everytime a new release of 
>> a component package is done. is this a good thing at the end?
> 
> 
> Only for the direct dependencies of ECM.  These dependencies are:
> 
> Logger, Instrument, Instrument-Manager, (AltRMI is in the big jar
> too), and Pool.
> 
> Truth is that there won't be alot of major changes to those JARs.
> 
> You have a choice.  You can use the smaller jar that has *just*
> the ECM classes, and upgrade the other jars independently.
> 
> Keep in mind that the big jar option is what Cocoon used in the
> past when Excalibur was one big project.

And that's the reason why we moved from single jar to many different 
jars... but that was before those things were released.

anyway, I'm really +0 on such changes, I'll let more excalibur-wise 
people choose what to do.

>> As long as you provide feedback on how to migrate, we'll be happy to 
>> follow what is considered best practice.
> 
> 
> The first set of projects that are already in the draft compatibility
> JAR are: Concurrent, Collections, IO, and CLI.
> 
> With the exception of Excalibur CLI, I believe that Cocoon does not
> have any dependencies on those libraries.

Then it would be kinda cool to remove all those dependencies right now 
and forget about it so one less jar into the classpath.

> We want to point our users to Jakarta Commons CLI--which is just as
> capable.  The end user will never know the difference with the change.

Cool.



Mime
View raw message