cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [Avalon] Trying to coordinate some releases
Date Thu, 20 Feb 2003 17:32:44 GMT
Over in Avalon land, we are wanting to coordinate the releases
of the Avalon technologies.  We recently released LogKit 1.2
(available at http://avalon.apache.org/bindownload.cgi), and
very soon we will be releasing Framework 4.1.4.

Next on the agenda is the Excalibur stuff.  We will focus
primarily on the suite of components used for the ECM which
Cocoon uses, and then expand to include all the Avalon
components that Cocoon uses.  THe latest stuff and all new
releases should be guaranteed to work against the latest
and greatest released products (at least that is the plan).

 From what I can gather, Cocoon uses all of these components
from Avalon:

CLI
Collections
Concurrent
i18n
instrument
instrument-manager
instrument-manager-interfaces
IO
Logger
Monitor
Naming
Pool
SourceResolve
Store
XMLUtil
Cornerstone
Cornerstone-excalibur-thread
Cornerstone-excalibur-threadcontext
DataSource
AltRMI
AltRMI Registry
AltRMI Server (IMpl/Interfaces)
Component (AKA ECM)


I would like to provide a heads up on Collections and
Concurrent.  They are considered deprecated, and are only
included for backwards compatibility.  They will no longer
be maintained.  They are superceded by the much better and
more robust libraries of Commons Collections and Doug Lea's
concurrency utils.

I would highly recommend updating the Cocoon code base with
those libraries--although you should include the old excalibur
JARs for backwards compatibility with your clients.

On the same token, we are looking into officially deprecating
Excalibur CLI in favor of COmmons CLI.  THere is no official
word on that yet, but the general trend is that the Avalon
project only wants to host components that are truly Avalon
components, and not merely APIs or libraries.  Commons is a
much better place for library code.

That said, I personally would like to understand how Cocoon
is using the Cornerstone code.  We really aren't ready to
get to the Cornerstone code for a little while yet, so
I would like to know what part of it is being used.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message