cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [GUMP] Good news and bad
Date Fri, 14 Mar 2003 20:33:41 GMT
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>> First the good news:
>> Avalon is no longer the problem preventing GUMP builds.  As Avalon has
>> been going through its growing pains in its infancy, we have been taking
>> some serious strides toward stability and simplifying our code base.
>> As part of that effort, we are releasing all the Avalon components so
>> that all releases from this year forward (including LogKit 1.2,
>> Framework 4.1.4 which were released earlier this year) will be
>> guaranteed to interroperate.  We also took strides to make sure we
>> have compatibility and make sure that GUMP does not fail as a result
>> of our activities.
>> It has been painful, but I think we are better for it.
> Awesome!!! Thanks much for your work on this.
>> Now, the bad news:
>> Cocoon still does not compile with GUMP.  Currently the problem is with
>> FOP.
> Err, no. The 'fop-block' doesn't compile. Cocoon-core does. it's simply 
> the gump target that is dependent on the 'block' target and it shouldn't 
> be.
> I'm fixing this right away.
>> 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.

>> After that, we will be releasing a "Compatibility" jar which is
>> for the sole expressed purpose of providing binary compatibility
>> with code that has been using us for a while.  This compatibility
>> JAR will again allow you to replace a few CVS jars for that one.
>> There are no Avalon dependencies on the classes in that JAR--although
>> there might be some Cocoon dependencies.
> Removing that jar from classpath should be


I am assuming you are meaning to say "trivial"?

It would only be needed to maintain backwards binary compatibility
with users of Cocoon that may have used the contents of those utilities.

>> Avalon is getting out of the business of maintaining utility jars,
>> and focusing on components, containers, and the contracts (framework)
>> between them.  As we remove these libraries from the officially
>> supported list of Avalon subprojects they will be moved into the
>> compatibility JAR and a replacement will be available.
> 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.

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.

View raw message