Large parts of Loom and the idea itself have been around for a long time. Here we discuss its history and describe the projects that finally led to the Loom project.
Loom is a fork of the Apache Avalon Phoenix project. The Loom project started here at Codehaus in 2003. The initial codebase consisted of the unreleased phoenix-4.1 development branch. When moving to Codehaus some parts were rewritten, for example all internal components were changed to follow DNA lifecycle interfaces instead of Avalon.
Avalon was originally started with a realization that Java is a great platform for developing server products and a call to vote. There was a lot of work formalizing what exactly a server consists of and why this project was needed. These discussions led to the initial development of the Java Apache Server Framework.
Avalon then 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. The framework focused a small number of core concepts (design patterns) called Separation of Concerns and Inversion of Control.
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.
In the fall of 2004, the Avalon project at Apache closed its doors. The Avalon Framework is now hosted at Excalibur.
Excalibur held a set of basic components and utilities which made working with the Avalon 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.
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 among others.
Phoenix was the first 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.
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.
To have a place for ready made Phoenix blocks a new project was founded, Cornerstone.
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.
Original text from the Avalon development team