Leo Simons wrote:
+100! I also kind-of had the idea to do a bit more integration of the
excalibur and cornerstone website, perhaps do a common catalogue.
Quickly threw up http://avalon.apache.org/components/index.html for that.
Be sure to harvest
http://www.osm.net/technical/avalon/docs/avalon.html (Steve, can you
provide the sourcefiles to those?) :D
Sure - attached.
Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
<?xml version="1.0"?>
<document>
<properties>
<title>App Product Table</title>
</properties>
<body>
<section name="Projects">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Corbaloc</p></td>
<td><p>1.0</p></td>
<td><p>BETA</p></td>
<td>
<p>Component supporting the management of corbaloc urls.</p>
<p>Dependencies: apps orb 2.0; assembly 1.0</p>
</td>
</tr>
<tr>
<td><p>INS</p></td>
<td><p>2.0</p></td>
<td><p>BETA</p></td>
<td><p>
Interoperable Naming Service</p>
<p>Dependencies: apps orb 2.0; assembly 1.0</p>
</td>
</tr>
<tr>
<td><p>ORB</p></td>
<td><p>2.0</p></td>
<td><p>BETA</p></td>
<td>
<p>Componet based implementation of a CORBA 2.4 ORB.</p>
<p>Dependencies: framework 4.1; assembly 1.0</p>
</td>
</tr>
<tr>
<td><p>PSS</p></td>
<td><p>2.0</p></td>
<td><p>BETA</p></td>
<td>
<p>Persistent state service (PSS).</p>
<p>Dependencies: framework 4.1; assembly 1.0</p>
</td>
</tr>
<tr>
<td><p>Time</p></td>
<td><p>2.0</p></td>
<td><p>BETA</p></td>
<td>
<p>Component based implementation of the CORBA Time Service.</p>
<p>Dependencies: excalibur datasource 1.0; excalibur pool 1.2</p>
</td>
</tr>
<tr>
<td><p>FTP Server</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td>
<p>FTP server implementation.</p>
<p>Dependencies: ????</p>
</td>
</tr>
<tr>
<td><p>HSQL</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td>
<p>???</p>
<p>Dependencies: ????</p>
</td>
</tr>
<tr>
<td><p>Overlord</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td>
<p>???</p>
<p>Dependencies: ????</p>
</td>
</tr>
<tr>
<td><p>Phyre</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td>
<p>???</p>
<p>Dependencies: ????</p>
</td>
</tr>
<tr>
<td><p>Servac</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td>
<p>???</p>
<p>Dependencies: ????</p>
</td>
</tr>
<tr>
<td><p>XCommander</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td>
<p>???</p>
<p>Dependencies: ????</p>
</td>
</tr>
</table>
</section>
</body>
</document>
<?xml version="1.0"?>
<document>
<properties>
<title>Avalon Product Table</title>
</properties>
<body>
<section name="Releases">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Framework</p></td>
<td><p>4.1.1</p></td>
<td><p>RELEASED</p></td>
<td><p>
Avalon component model API (pre-Service package).
</p></td>
</tr>
<tr>
<td><p></p></td>
<td><p>4.1.2</p></td>
<td><p>WITHDRAWN</p></td>
<td><p>
Basically 4.1.2 is a badly packaged release that should be ignored - it was intended to include the service package but the release was stuffed up somewhere along the line resulting in the release of 4.1.3 that fixed the problem.
</p></td>
</tr>
<tr>
<td><p></p></td>
<td><p>4.1.3</p></td>
<td><p>RELEASED</p></td>
<td><p>
Includes the service package which replaces the component package (delivering a significantly more open solution and reduced framework dependency).
</p></td>
</tr>
</table>
</section>
<section name="Sandbox">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Framework</p></td>
<td><p>5.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Work in progress relating to the clean client component API based on the knowlege aquired through the V4 process. </p>
</td>
</tr>
</table>
</section>
</body>
</document>
<?xml version="1.0"?>
<document>
<properties>
<title>Phoenix Product Table</title>
</properties>
<body>
<section name="Releases">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Phoenix</p></td>
<td><p>4.0.3</p></td>
<td><p>RELEASED</p></td>
<td><p>
App server that provides support for delopment of applications built using a Phoenix metainfo descriptor.
</p></td>
</tr>
<tr>
<td><p></p></td>
<td><p>CVS HEAD</p></td>
<td><p></p></td>
<td><p>
Substantial changes exist in the CVS HEAD version including incorporation of a number of alpha products (Containerkit, Info, loader, etc.). This changes enable inital support for auto assembly, will provide improved meta info management, and enable configurable classloaders.
</p></td>
</tr>
</table>
</section>
<section name="Development">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Fortress</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td><p>
Fortress is a replacement for Excalibur's component package. It
makes it easier to build your own scalable containers. It
separates the Container logic from the component accessor logic.
</p></td>
</tr>
</table>
</section>
<section name="Sandbox">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Merlin</p></td>
<td><p>2.1</p></td>
<td><p>ALPHA</p></td>
<td>
<p>A next generation container providing:</p>
<p>
<ul>
<li>leverages and enhances the notion of meta based management from phoenix and the work on Merlin 1.0 and 2.0</li>
<li>provides support for dynamic component assembly and deployment</li>
<li>manages a set of "blocks" (where a block is a container hierachy that can contain components and other blocks - and is itself a component)</li>
<li>containers represent the runtime management environment for the set of contained components - it provides support for orderly component startup and shutdown</li>
<li>full support for different component lifestyles</li>
<li>suppport for pluggable lifecycle strategies</li>
<li>fully embeddable</li>
<li>existing support for Phoenix components</li>
</ul>
<p>With planned support for:</p>
<ul>
<li>ECM/Fortress components</li>
<li>block level asembly</li>
<li>remote service integration</li>
</ul>
</p>
</td>
</tr>
</table>
</section>
</body>
</document>
<?xml version="1.0"?>
<document>
<properties>
<title>Avalon Product Table</title>
</properties>
<body>
<section name="Releases">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>cli</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>The CLI component is a set of classes that allow you to parse
command line arguments. It parses command line arguments that
conform to the GNU "standard" for command line arguments.</p>
<p>Dependencies: none</p>
</td>
</tr>
<tr>
<td><p>component</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>This project contains utilities for managing components. In particular, the ExcaliburComponentManager. Based on mailing list opinions, this package is not longer maintained and the objectives are to provide the Fortress package as a replacement.</p>
<p>Dependencies: framework 4.1; logkit 1; event 1.1; collections 1.0; logger 1.0; pool 1.2; i18n 1.1</p>
</td>
</tr>
<tr>
<td><p>datasource</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>Used within the Cocoon and Cornerstone projects which is turn is used within the James project. Contains some alpha level jars.</p>
<p>Dependencies: framework 4.1.3; logkit 1; pool 1.2</p>
</td>
</tr>
<tr>
<td><p>event</p></td>
<td><p>1.0.1</p></td>
<td><p>RELEASED</p></td>
<td>
<p>This is the Excalibur Event package which includes event queues, asynchronous command processing, and the interfaces to support event based programming. Fortress uses this project to manage the components and its pools outside of the direct thread of execution.</p>
<p>Dependencies: framework 4.1.3; logkit 1; pool 1.2</p>
</td>
</tr>
<tr>
<td><p>i18n</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>The i18n component is a set of classes that allow you to
manage internationalization in your projects. </p>
<p>Dependencies: none</p>
</td>
</tr>
<tr>
<td><p></p></td>
<td><p>CVS</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>Minor update to ResourceManager to enable explicit declaration of locale. </p>
<p>Dependencies: none</p>
</td>
</tr>
<tr>
<td><p>logger</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>Logging utilities.</p>
<p>Dependencies: framework 4.1.3; logkit 1</p>
</td>
</tr>
<tr>
<td><p>monitor</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>Monitor is a component that will actively notify you if a resource
has changed. For example, if you are caching data in Files, Monitor
will let you know when to update your cache with an event. It is
designed to reduce the number of system calls in highly concurrent
environments.</p>
<p>Dependencies: framework 4.1; logkit 1.0; logger 1.0; sourceresolve 1.0</p>
</td>
</tr>
<tr>
<td><p>naming</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>Utilities suport simplified management of a JNDI context.</p>
<p>Dependencies: none</p>
</td>
</tr>
<tr>
<td><p>pool</p></td>
<td><p>1.1</p></td>
<td><p>RELEASED</p></td>
<td>
<p>Support for object pools.</p>
<p>Dependencies: framework 4.1; i18n 1.1</p>
</td>
</tr>
<tr>
<td><p>thread</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>Utilities supporting thread management.</p>
<p>Dependencies: framework 4.1; threadcontext 1.0; pool 1.2; collections 1.0</p>
</td>
</tr>
<tr>
<td><p></p></td>
<td><p>1.1</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>The 1.1 version includes changes to the thread pool constructor that ensures max pool usage policy is propergated.</p>
</td>
</tr>
<tr>
<td><p>threadcontext</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td>
<p>The ThreadContext defines a set of data that is associated with a particular thread. In particular this is useful as a location to centralize management of ThreadLocal-type variables. As such the type of data contained in ThreadContext is usually data such as ContextClassLoader, Transaction ID, User ID/Subject, etc. </p>
<p>Dependencies: none</p>
</td>
</tr>
</table>
</section>
<section name="Depricated">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>bzip2</p></td>
<td><p>1.0</p></td>
<td><p>DEPRICATED</p></td>
<td><p>
Package has been moved to Jakarta
Commons Sandbox under the package org.apache.commons.io.compress.bzip2.*
</p></td>
</tr>
<tr>
<td><p>collections</p></td>
<td><p>1.0</p></td>
<td><p>DEPRICATED</p></td>
<td><p>
This package has been copied in the Jakarta Commons Sandbox under the project collections. The new package name is
org.apache.commons.collections.* No vote on migration has been taken at the Avalon level. The Avalon Collections API is in use with client projects.
</p></td>
</tr>
<tr>
<td><p>io</p></td>
<td><p>1.1</p></td>
<td><p>DEPRICATED</p></td>
<td><p>
This package has been copied in the Jakarta
Commons Sandbox under the project io. The new package name is org.apache.commons.io.*
</p></td>
</tr>
<tr>
<td><p>tar</p></td>
<td><p>1.0</p></td>
<td><p>DEPRICATED</p></td>
<td><p>
This package has been copied in the Jakarta
Commons Sandbox under the project io. The new package name is
org.apache.commons.io.compress.tar.*
</p></td>
</tr>
<tr>
<td><p>zip</p></td>
<td><p>1.0</p></td>
<td><p>DEPRICATED</p></td>
<td><p>
This package has been copied in the Jakarta
Commons Sandbox under the project io. The new package name is
org.apache.commons.io.compress.zip.*
</p></td>
</tr>
</table>
</section>
</body>
</document>
<?xml version="1.0"?>
<document>
<properties>
<title>Avalon Product Table</title>
</properties>
<body>
<section name="Excalibur Development">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Altrmi</p></td>
<td><p>0.8</p></td>
<td><p>ALPHA</p></td>
<td><p>
Alternative remote method invocation.
</p></td>
</tr>
<tr>
<td><p>baxter</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Baxter is a set of base classes and utility classes that enable
rapid creation of MBeans via delegation and inheritance. These were
originally derived from the Phoenix project.
</p></td>
</tr>
<tr>
<td><p>cache</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
The Cache component is a set of classes that allow you to cache
objects to memory. It gives you a flexible and plugable API
to allow you to specify the exact policies you want.
</p></td>
</tr>
<tr>
<td><p>configuration</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td><p>
Utilities supporting the management of Avalon Configurations. Used within Merlin and Phoenix.
</p></td>
</tr>
<tr>
<td><p>converter</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
</p></td>
</tr>
<tr>
<td><p>csframework</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
C# implementation of the Avalon framework.
</p></td>
</tr>
<tr>
<td><p>extension</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Utility classes used to manage jar file depedencies. Used with Phoenix and Merlin.
</p></td>
</tr>
<tr>
<td><p>instrument</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Classes supporting instrumentation of a component. Currently has depedencies on AltRMI which can be removed. Is used by several projects.
</p></td>
</tr>
<tr>
<td><p>jprocess</p></td>
<td><p>0.99</p></td>
<td><p>ALPHA</p></td>
<td><p>
</p></td>
</tr>
<tr>
<td><p>loader</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Classloader utilities used with Phoenix.
</p></td>
</tr>
<tr>
<td><p>sourceresolver</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>The source resolver of Avalon Excalibur is a component helping you in the task of finding a source using a URI. It resolves sources from a given URI. The URI can use all available protocols of the JRE. In addition own protocols can be plugged-in. So using the standard protocols like HTTP, FTP or file can be handled in the same way, like dealing with custom, self-build protocols such as myxmldatabase://root/documents/test.xml. The main advantage in comparisson to the mechanisms provided by the JRE is that the source resolver can be used without any problems with web application servers. Each web application can use it's own configured version of this component avoiding any possible conflicts between these applications. </p>
<p>Dependencies: framework 4.1.3; pool 1.2</p>
</td>
</tr>
<tr>
<td><p>policy</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Security policy management.
</p></td>
</tr>
<tr>
<td><p>store</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td><p>
???
</p></td>
</tr>
<tr>
<td><p>util</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
utilities that are either legacy, or new.
Usually the utilities that have been hosted here have been moved
to a new location that better fits their purpose. For example,
SystemUtil has been moved to "Event". The Delegate stuff in there
is new, and it is working, but it might be better to move into
a larger context.
</p></td>
</tr>
<tr>
<td><p>xfc</p></td>
<td><p></p></td>
<td><p>ALPHA</p></td>
<td><p>
Project dealing with meta info conversion.
</p></td>
</tr>
<tr>
<td><p>xmlutil</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td><p>
???
</p></td>
</tr>
</table>
</section>
<section name="Sandbox">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Assembly</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
Generic container framework supporting meta driven component assembly, deployment, decommissioning and dissassembly. The assembly package is under active development and as such the API are changing. The API is used as the service and component management engine within the Merlin 2.1 container.
</p>
<p>Features include:</p>
<ul>
<li>Type meta-info repository</li>
<li>Service meta-info repository</li>
<li>Deployment template (profile) meta-data repository</li>
<li>Deployment manager (appliance) system</li>
<li>Unified context/service management model</li>
<li>Preliminary model for pluggable lifecycle strategies</li>
<li>Dynamic component assembly services</li>
</ul>
</td>
</tr>
<tr>
<td><p>Datasource</p></td>
<td><p>1.0</p></td>
<td><p>ALPHA</p></td>
<td><p>
The Sandbox version is meant to correct some of the issues with the
older version (Excalibur Datasource):</p>
<p>
<ul>
<li>Interface assumes one to one relationship with DB and the rest of
the system. In the new version we have a DatabaseManager that
will allow you to get a connection by name.</li>
<li>Easier integration with javax.sql.DataSource implementations by
DB vendors. All the "big boys" have very well tested connection
pooling code developed and tested. We should be able to use it
directly--without having to go through JNDI.</li>
<li>Easier compilation--no need to distinguish between JDBC 3.0 and
JDBC 2.0 because we will use dynamic proxies or PooledConnection
style objects (references the connection instead of extending it).</li>
<li>Pooling of prepared statements. This is something that has not
been done yet.</li>
</ul>
</p>
</td>
</tr>
<tr>
<td><p>Meta</p></td>
<td><p>1.0</p></td>
<td><p>BETA</p></td>
<td><p>
Meta information and meta data classes used by the assembly package.
</p>
<p>Features include:</p>
<ul>
<li>Type meta-info classes</li>
<li>Service meta-info classes</li>
<li>Legacy meta-model support</li>
<li>Meta builders and validators</li>
</ul>
</td>
</tr>
<tr>
<td><p>Tweety</p></td>
<td><p>1.0</p></td>
<td><p>BETA</p></td>
<td><p>
Tutorial product the demonstrations a minimal container.
</p></td>
</tr>
</table>
</section>
</body>
</document>
<?xml version="1.0"?>
<document>
<properties>
<title>Logkit Product Table</title>
</properties>
<body>
<section name="Releases">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Logkit</p></td>
<td><p>1.0</p></td>
<td><p>RELEASED</p></td>
<td><p>
LogKit is an easy to use logging toolkit designed
for secure performance oriented logging. It's design
encourages integration into existing products
with minimal impact.
</p></td>
</tr>
<tr>
<td><p></p></td>
<td><p>1.1</p></td>
<td><p>RELEASED</p></td>
<td><p>
Additional logging targets added to package together with some bug fixes to the implementation of the file rotation strategy.
</p></td>
</tr>
</table>
</section>
</body>
</document>
<?xml version="1.0"?>
<document>
<properties>
<title>Cornerstone Product Table</title>
</properties>
<body>
<section name="Projects">
<table>
<tr>
<td><p>Product</p></td>
<td><p>Version</p></td>
<td><p>Status</p></td>
<td><p>Notes</p></td>
</tr>
<tr>
<td><p>Connection</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>Component supporting connection management.</p>
<p>Dependencies: cornerstone threads 1.0</p>
</td>
</tr>
<tr>
<td><p>Store</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td><p>
Component that provides support for selection from a number of configured repositories.</p>
<p>Dependencies: framework 4.1; excalibur io 1.0</p>
</td>
</tr>
<tr>
<td><p>Scheduler</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>A component that provides support for job scheduling.</p>
<p>Dependencies: framework 4.1</p>
</td>
</tr>
<tr>
<td><p>Sockets</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>A component that provides support for socket management.</p>
<p>Dependencies: framework 4.1</p>
</td>
</tr>
<tr>
<td><p>Datasources</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>A component that provides support for data source selection.</p>
<p>Dependencies: excalibur datasource 1.0; excalibur pool 1.2</p>
</td>
</tr>
<tr>
<td><p>Threads</p></td>
<td><p>1.0</p></td>
<td><p>CANDIDATE</p></td>
<td>
<p>A component that provides support for thread management.</p>
<p>Dependencies: excalibur threads 1.0; excalibur threadcontext 1.1</p>
</td>
</tr>
</table>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
