You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by fa...@apache.org on 2004/06/16 22:50:00 UTC
svn commit: rev 21362 - in avalon/trunk/central/site/src/xdocs: central/community/history products products/legacy
Author: farra
Date: Wed Jun 16 13:49:59 2004
New Revision: 21362
Added:
avalon/trunk/central/site/src/xdocs/central/community/history/story.xml
avalon/trunk/central/site/src/xdocs/products/legacy/
avalon/trunk/central/site/src/xdocs/products/legacy/index.xml
avalon/trunk/central/site/src/xdocs/products/legacy/navigation.xml
Modified:
avalon/trunk/central/site/src/xdocs/central/community/history/navigation.xml
avalon/trunk/central/site/src/xdocs/products/navigation.xml
Log:
Added legacy products page and more history docs
Modified: avalon/trunk/central/site/src/xdocs/central/community/history/navigation.xml
==============================================================================
--- avalon/trunk/central/site/src/xdocs/central/community/history/navigation.xml (original)
+++ avalon/trunk/central/site/src/xdocs/central/community/history/navigation.xml Wed Jun 16 13:49:59 2004
@@ -23,6 +23,7 @@
<body>
<menu>
+ <item name="Avalon's Story" href="story.html"/>
<item name="Call To Vote" href="call-to-vote.html"/>
<item name="Need For Avalon" href="need-for-avalon.html"/>
<item name="What is a Server?" href="what-is-a-server.html"/>
Added: avalon/trunk/central/site/src/xdocs/central/community/history/story.xml
==============================================================================
--- (empty file)
+++ avalon/trunk/central/site/src/xdocs/central/community/history/story.xml Wed Jun 16 13:49:59 2004
@@ -0,0 +1,259 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- edited with XMLSPY v2004 rel. 2 U (http://www.xmlspy.com) by J Aaron Farr (Sony Electronics) -->
+<document>
+ <properties>
+ <author email="dev@avalon.apache.org">Avalon Documentation Team</author>
+ <title>History</title>
+ </properties>
+ <body>
+ <section name="Avalon's Story">
+ <p>
+ The following is an attempt at recording the history of
+ Avalon, both its technology and its community. The Avalon Framework
+ traditionally had a notorious learning curve and the community
+ has seen a number of changes. Hopefully by understanding
+ where Avalon has been, users can gain a better understanding of
+ where Avalon is now and where we are headed.
+ </p>
+ </section>
+ <section name="Once upon a time">
+ <p>
+Let's start off with some basic history. Avalon emerged from the Java
+Apache Server Framework before the days of Apache Jakarta. During
+development of the JServ project (which laid the foundation for
+Tomcat), many of the developers realized that the ideas being used at
+the time could be abstracted into a general application
+framework. This framework eventually became the Avalon framework we
+have today. The framework focused a small number of core concepts
+(design patterns) called Separation of Concerns and Inversion of
+ Control which are described elsewhere.
+ </p>
+ <p>
+So in the beginning there was the Avalon Framework. It basically
+described the contracts or interfaces between various components (such
+as lifecycle methods) and provided some general utilities for using
+these interfaces. One could easily create an application which simply
+just used the framework. However, in order to provide some more
+advanced components and utilties (which were not essential to the
+framework, but still useful) Excalibur was born.
+ </p>
+ <p>
+Excalibur held a set of basic components and utilities which made
+working with the Framework much easier. One of these components was
+the Excalibur Component Manager or ECM which did all the work of
+getting all your component and configuration data sorted out and
+started. It was the first container of sorts and grew out of work from
+the Cocoon project. ECM didn't have a lot of "advanced" features, but
+it was simple to work with and could be used in any number of
+environments.
+ </p>
+ <p>
+Of course, with time, new expectations and requested features meant
+that other Avalon containers were under development. ECM would have to
+share the spotlight with Phoenix.
+ </p>
+ </section>
+ <section name="The Rise of the Phoenix">
+ <p>
+Phoenix was the first really complete full fledged standalone
+container for Avalon. Phoenix was not only a container, but a
+microkernel. While it could be used for other sorts of applications,
+most Phoenix development revolved around server applications such as
+web servers, FTP servers, telnet servers, etc. Phoenix applications
+would take a number of components and bundle them together in what was
+called a block. A block generally referred to a complete application,
+such as a database or FTP server, although you could have inter-block
+dependencies. Blocks would be packaged up with configuration and
+assembly files into a .sar archive, similar to the .ear files for J2EE
+applications. Phoenix would then launch all the SAR blocks contained
+within a particular startup directory.
+ </p>
+ <p>
+Thus Phoenix was a full application server of sorts. Applications
+running within Phoenix used the Avalon Framework just as ECM
+components would. In fact, if you were careful to only depend on the
+framework for development, with a little work you could get
+applications written for ECM to run in Phoenix and visa versa.
+ </p>
+ <p>
+Cornerstone became a repository of Phoenix blocks: larger components
+which could be dropped into Avalon Phoenix and provide services and
+resources to user developed components and applications. There was
+some overlap between components developed in Cornerstone and
+Excalibur, but in general, Cornerstone components were targeted for
+server side applications running in Phoenix.
+ </p>
+ <p>
+Phoenix's growth brought changes to the developer community as well.
+A separate CVS repository and specific mailing list were
+created to facility the Phoenix community. This was the beginning
+of a sort of schism within Avalon, both technologically and socially,
+as the new containers created with them their own communities,
+standards, and goals. There was a a tug of war, so to speak, between
+keeping the different containers compatible while also allowing each
+developer community to explore and enhance their software in their own
+repective ways. One of those enhancements was the change from
+components to services.
+ </p>
+ </section>
+ <section name="How Components Became Services">
+ <p>
+In the beginning there were only components. The components had a role
+defined by a java interface and an implementation defined by a
+concrete java class. In ECM roles and components could be described in
+a set of XML configuration files, generally one for the roles and one
+for the implementations. In Phoenix, roles were still roles and
+components were still components, but they were defined in xinfo files
+scattered across the various jar archives that would make up an
+application. This was done to allow developers to deploy a jar file
+that contained not only the interfaces and implementations, but also
+the basic meta-data. The xinfo files and the conf files had the
+same purpose (to hold meta-data and meta-info) but were used by
+different containers. Thus, from the beginning there was no common
+meta format or API.
+ </p>
+ <p>
+Also at this time, all components were children of the one
+org.apache.framework.component.Component interface. A brave developer
+scaled Mt. Doom and tossed the Component interface and all the other
+marker interfaces into the fiery pit, thus freeing all components from
+bondage of the one Component.
+ </p>
+ <p>
+Upon return from this quest, the developer said, "All Components shall
+now be dubbed Services" and a new set of Service Managers and Service
+Selectors appeared that could converse with any Object, not just
+Components. These Service utilities performed the exact same functions
+as their deprecated Component counterparts, but didn't require
+everything be a Component. That is:
+ </p>
+ <source>
+ Component componentManager.lookup(String role);
+ </source>
+ <p>
+became
+ </p>
+ <source>
+ Object serviceManager.lookup(String role);
+ </source>
+ <p>
+So in this sense, Components ARE Services. But now the Avalon
+community had two names for the same thing and this is generally were
+confusion arises. Since that time, a service generally refers to only
+the service interface while a component refers to the entire interface
+and implementation together.
+ </p>
+ <p>
+Stephen McConnell, primary developer of Merlin, chimed in with this
+clarification: "A 'component' is an implementation artifact that
+exposes 0..n services. A 'service' is computation contract exposed by
+a component. A component may include many other features that are not
+exposed through the services that is publishes. "
+ </p>
+ <p>
+"A 'service' is typically represented by a Java interface and possibly
+supporting meta-info (such as a version, attributes, etc.)."
+ </p>
+ <p>
+"A 'component' is an example of a 'service-delivery-strategy'."
+ </p>
+ </section>
+ <section name="Fortress and Merlin arrive">
+ <p>
+Effort was made in Phoenix to support the new Service semantics, but
+instead of rewritting ECM, the decision was made to create a new
+ECM-like container which could use Components and Services alike. Thus
+was born Fortress.
+ </p>
+ <p>
+Fortress supports legacy ECM components but provides a number of
+features like basic meta-data configuration (instead of a "roles"
+file), dynamic service activation, lifecycle extensions,
+instrumentation support and so on. Fortress is also "embeddable" in
+that you can easily start up a Fortress container in your own
+application be it a Java Swing client or a Servlet. Fortress provides
+no default standalone client (i.e.- there's no "main" method class in
+Fortress) and doesn't do much classloader magic, making embedding a
+little more predictable. Fortress was released in the summer of 2003
+and replaced ECM as Avalon's light weight container of choice.
+ </p>
+ <p>
+While Fortress grew from ECM, Merlin grew from Phoenix, though it
+quickly developed beyond its roots. Merlin focused on a strict
+seperation between container concerns and component concerns. As such,
+all Merlin applications are never dependent on any actual Merlin code
+(at least in order to compile). A new meta data model was developed,
+hierarchical block support added, and Merlin provided support for
+standalone or embedded environments.
+ </p>
+ <p>
+For the sake of completeness, we should also mention Tweety which was
+a very basic container developed for the sole purpose as a teaching
+tool. Tweety never really made it out of the sandbox much, but it
+is not forgotten by some ...
+ </p>
+ </section>
+ <section name="One container to rule them all">
+ <p>
+If you're keeping up with our story you'll have realized by now that
+we have four containers: ECM, Phoenix, Fortress, Merlin. At its
+height, Avalon also contained its own logging framework (LogKit), unit
+testing framework, two component libraries (Excalibur and
+Cornerstone), and a host of Avalon-based server applications including
+a web server and FTP server. It was a lot to handle.
+ </p>
+ <p>
+Moreover, while all of these software projects and components were
+based on the same Avalon framework, they were often mutually
+incompatible. The framework was intentionally designed to be
+rather silent on the issues of meta-info and meta-data (information
+about how to wire components together inside a container) amongst
+other things. This meant that each container implementation had its
+own "standards" and made writing container neutral components rather
+difficult.
+ </p>
+ <p>
+When Avalon moved out of Apache Jakarta in late 2002 and on to its own
+top level project, the developers decided to try to organize the
+situation; however, they faced a bit of an identity crisis: What was
+Avalon about? Containers? Frameworks? Components? All of the
+above? Was Avalon to be an umbrella project with many containers
+based on a single framework or a single project with a single
+reference implementation?
+ </p>
+ <p>
+To make a long story short, the pendulum swung back and forth on that
+issue for the better part of two years. Several projects where spun
+off or depricated and some developers left to persue other adventures.
+In the spring of 2004 there was another push to consolidate Avalon's
+software projects into a single platform:
+ </p>
+ <source>
+ One container to rule them all
+ One container to find them
+ One container to bring them all
+ And in the model bind them
+ </source>
+ <p>
+After a few months of proposals and counter proposals, Avalon emerged
+as a project focused on a single container platform: Merlin. The
+Fortress and Excalibur codebases were then transferred to the new <a href="http://excalibur.apache.org">Apache Excalibur</a> project.
+Meanwhile, Phoenix was retired in light of its fork, <a href="http://loom.codehaus.org">Loom</a>, which was developed at
+Codehaus by some early Avalon developers.
+ </p>
+ </section>
+ <section name="Peering into the Mysts of Avalon">
+ <p>
+At its inception, Avalon was a rather novel software project and
+pioneered many ideas in container development. Since that time, the
+concepts of Separation of Concerns and Inversion of Control have
+become buzzwords and a whole slew of IoC frameworks and containers
+have emerged. Avalon continues to push the bounds of these
+technologies and remains focused on developing a complete solution for
+component and container applications. The Avalon team invites you to
+download our software and join our community mailing lists and become
+involved in Avalon's future.
+ </p>
+ </section>
+ </body>
+</document>
Added: avalon/trunk/central/site/src/xdocs/products/legacy/index.xml
==============================================================================
--- (empty file)
+++ avalon/trunk/central/site/src/xdocs/products/legacy/index.xml Wed Jun 16 13:49:59 2004
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="dev@avalon.apache.org">Avalon Documentation Team</author>
+ <title>Legacy Products</title>
+ </properties>
+
+ <body>
+ <section name="Legacy Avalon Products">
+ <p>
+ Several Apache Avalon products have been either retired or
+ spun off into their own Apache projects. For a more detailed
+ record of Avalon's evolution, see the
+ <a
+ href="http://avalon.apache.org/central/community/history/index.html">
+ history</a> section.
+ </p>
+ <table>
+ <tr>
+ <th>Product</th>
+ <th>Description</th>
+ <th>Current Status</th>
+ </tr>
+ <tr>
+ <td>Excalibur</td>
+ <td>Excalibur included a component library as well as the
+ Excalibur Component Manager (ECM) -- a minimal Avalon
+ container.
+ </td>
+ <td>
+ Graduated to it's own ASF Project:
+ <a href="http://excalibur.apache.org">Apache Excalibur</a>
+ </td>
+ </tr>
+ <tr>
+ <td>Fortress</td>
+ <td>Fortress is a lightweight Avalon container designed to
+ to be the successor to ECM.
+ </td>
+ <td>Now part of the
+ <a href="http://excalibur.apache.org">Apache Excalibur</a>
+ Project
+ </td>
+ </tr>
+ <tr>
+ <td>Phoenix</td>
+ <td>Avalon Phoenix is an Avalon 4 container designed to be
+ used as an application server framework.
+ </td>
+ <td>Active development halted. See distribution mirrors for
+ prior releases and documentation. Also, see Codehaus'
+ <a href="http://loom.codehaus.org">Loom</a> project, a
+ fork of Phoenix.
+ </td>
+ </tr>
+ <tr>
+ <td>Logkit</td>
+ <td>LogKit is a full logging framework similar to Log4J.</td>
+ <td>LogKit is stable and used in many products but not
+ actively developed. Many logkit utilities (ie- Excalibur
+ Logging) are now part of the
+ <a href="http://excalibur.apache.org">Apache Excalibur</a>
+ Project.
+ </td>
+ </tr>
+ </table>
+ </section>
+ </body>
+</document>
+
Added: avalon/trunk/central/site/src/xdocs/products/legacy/navigation.xml
==============================================================================
--- (empty file)
+++ avalon/trunk/central/site/src/xdocs/products/legacy/navigation.xml Wed Jun 16 13:49:59 2004
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!--
+ Copyright 2004 Apache Software Foundation
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied.
+
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<project>
+
+ <title>Apache Avalon Products</title>
+
+ <body>
+ <menu>
+
+ </menu>
+ </body>
+
+</project>
Modified: avalon/trunk/central/site/src/xdocs/products/navigation.xml
==============================================================================
--- avalon/trunk/central/site/src/xdocs/products/navigation.xml (original)
+++ avalon/trunk/central/site/src/xdocs/products/navigation.xml Wed Jun 16 13:49:59 2004
@@ -26,6 +26,7 @@
<item name="Merlin Runtime" href="runtime/index.html"/>
<!-- <item name="Merlin Studio" href="studio/index.html"/> -->
<item name="Merlin Discovery" href="discovery/index.html"/>
+ <item name="Legacy Avalon" href="legacy/index.html"/>
</menu>
</body>
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org