cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [GUMP] Good news and bad
Date Fri, 14 Mar 2003 20:13:45 GMT
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?

> 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

> 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.

> I will keep you posted as more details unfold.


View raw message