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