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.
