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