avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcconn...@apache.org
Subject svn commit: rev 21380 - avalon/trunk/central/site/src/xdocs/central/community/history
Date Thu, 17 Jun 2004 07:39:55 GMT
Author: mcconnell
Date: Thu Jun 17 00:39:54 2004
New Revision: 21380

Modified:
   avalon/trunk/central/site/src/xdocs/central/community/history/story.xml
Log:
removing tabs

Modified: avalon/trunk/central/site/src/xdocs/central/community/history/story.xml
==============================================================================
--- avalon/trunk/central/site/src/xdocs/central/community/history/story.xml	(original)
+++ avalon/trunk/central/site/src/xdocs/central/community/history/story.xml	Thu Jun 17 00:39:54
2004
@@ -1,23 +1,23 @@
 <?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>
+  <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.
+subsection</p>
+
+      <subsection 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
@@ -26,9 +26,9 @@
 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>
+subsectionControl 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
@@ -36,8 +36,8 @@
 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>
+      </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
@@ -46,15 +46,15 @@
 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>
+      </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>
+      </p>
+      </subsection>
+      <subsection 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,
@@ -67,23 +67,23 @@
 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>
+      </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>
+      </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>
+      </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
@@ -94,10 +94,10 @@
 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>
+      </p>
+      </subsection>
+      <subsection 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
@@ -111,61 +111,57 @@
 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>
+      </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>
+      </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>subsectionComponent componentManager.lookup(String role);</source>
+      <p>
 became
-   </p>
-			<source>
-      Object serviceManager.lookup(String role); 
-   </source>
-			<p>
+      </p>
+<source>subsectionObject 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>
+      </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>
+      </p>
+      <p>
 "A 'service' is typically represented by a Java interface and possibly
 supporting meta-info (such as a version, attributes, etc.)." 
-   </p>
-			<p>
+      </p>
+      <p>
 "A 'component' is an example of a 'service-delivery-strategy'."
-   </p>
-		</section>
-		<section name="Fortress and Merlin arrive">
-			<p>
+      </p>
+      </subsection>
+      <subsection 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>
+      </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,
@@ -176,8 +172,8 @@
 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>
+      </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,
@@ -185,24 +181,24 @@
 (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>
+      </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>
+      </p>
+      </subsection>
+      <subsection 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>
+      </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
@@ -211,8 +207,8 @@
 other things.  This meant that each container implementation had its
 own "standards" and made writing container neutral components rather
 difficult.
-   </p>
-			<p>
+      </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
@@ -220,30 +216,28 @@
 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>
+      </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>
+      </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>
+     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>
+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>
+      </subsection>
+      <subsection 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
@@ -253,7 +247,8 @@
 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>
+      </p>
+      </subsection>
+    </section>
+  </body>
 </document>

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


Mime
View raw message