Avalon Platform Diagram

The idea is, if you’re not familiar with Avalon, that Merlin takes three files - a block.xml, config.xml, and merlin.properties - to launch an appliction. The block.xml is an application “assembly” file, that is, it tells Merlin the names of the components which make up the application. Think of it as a web application’s web.xml file, though a block.xml file can do much more. For example, these blocks can be hierarchal (they can import components from other block.xml’s), embedded in a jar file or a standalone file, and can be local or remote (loaded via a URL). The config.xml specifies the configuration information for the block components. Default config values can be specified in the block.xml, so this file is optional. However, a config.xml allows you to override any default configuration values in a block.xml (which perhaps is remote or embedded in a jar file). The merlin.properties file specifies specific configuration values for the merlin kernel itself such as where to find local and remote repositories and what block file to load by default.

Essentially a block.xml describes an application made up of components. Components can be anything from a simple Swing frame to a web server or database. Not only can the block.xml file specify default configuration values, it also specifies what resources such as jar libraries the application needs. Merlin will then download the needed resources from a remote repository like ibiblio.org and place them into a local repository (like the Maven build system). This gives you a very clean application deployment solution—no more jar hell!

Merlin then loads the components or blocks which comprise the complete application much like Tomcat would load all the various servlets to create a full webapp or JBoss would load all the EJB’s for a J2EE app. Merlin also provides a number of extensions or “facilities” which the components can use like JMX, HTTP, or JMS support. There is also the underlying Avalon framework which specifies APIs for lifecycle support, reading config values, handing repositories, and component activation and composition. All of this resides in a single Java virtual machine.

In the end you have a complete application framework that can run anything from a web server to a desktop swing app. Pretty nice, huh? :)