avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fa...@apache.org
Subject svn commit: rev 21362 - in avalon/trunk/central/site/src/xdocs: central/community/history products products/legacy
Date Wed, 16 Jun 2004 20:50:00 GMT
Author: farra
Date: Wed Jun 16 13:49:59 2004
New Revision: 21362

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 @@
+      <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
@@ -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)
+	<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
+    </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>
+   </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
+   </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>

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"?>
+  <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>

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
@@ -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,
+ implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ <title>Apache Avalon Products</title>
+ <body>
+    <menu>
+    </menu>
+ </body>

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"/>

To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org

View raw message