[magic] block automation

[Stephen McConnell <mc...@apache.org>]

Just a note to let everyone know that I've added a BlockTask to Magic. 
The task provides support for the automatic generation of a container 
directive.  The following example is taken from cornerstone connection 
impl project (package names shorted for clarity):

   <target name="build" depends="standard.build">
     <x:block name="connection" embed="MAIN">
       <x:service source="manager"
         type="o.a.a.c.services.connection.ConnectionManager"/>
       <x:component name="manager"
         class="o.a.a.c.blocks.connection.DefaultConnectionManager"
         profile="default"/>
     </x:block>
   </target>

The above target results in the generation of the of two block 
definitions - one standalone, and the other embedded in the jar file 
produced by the project.

<?xml version="1.0" encoding="ISO-8859-1"?>

<container name="connection">

   <services>
     <service type="o.a.a.c.services.connection.ConnectionManager">
       <source>manager</source>
     </service>
   </services>

   <classloader>
     <classpath>
       <artifact>jar:a/c/cornerstone-connection-api#2.0.0</artifact>
       <artifact>jar:a/c/cornerstone-sockets-api#1.0.0</artifact>
       <artifact>jar:a/c/cornerstone-threads-api#2.0.0</artifact>
       <artifact>jar:e-thread/excalibur-thread-api#2.0.0</artifact>
       <artifact>jar:a/f/avalon-framework-api#4.3.0-DEV</artifact>
       <artifact>jar:a/f/avalon-framework-impl#4.3.0-DEV</artifact>
       <artifact>jar:a/f/avalon-framework-legacy#4.3.0-DEV</artifact>
       <artifact>jar:a/l/avalon-logkit#2.0.0</artifact>
       <artifact>jar:a/c/cornerstone-connection-impl#2.0.1-DEV</artifact>
     </classpath>
   </classloader>

   <component name="manager" profile="default"
     class="o.a.a.c.blocks.connection.DefaultConnectionManager"/>

</container>

Basically the magic contribution is the generation of the classloader 
information based on the transitive dependencies resolved from the 
index.  In addition to the above the block task also handles the 
declaration of multiple include directives and will soon have support 
for nested container directives.

One thing we could be doing is to make a distinction between jar file 
references in the classloader directive that are assumed to be available 
and jar files that are required as part of the implementation.  For 
example the publication of ConnectionManager assumes that the class (and 
all dependent classes are available within the containing classloader). 
  It would not take a lot of effort to evolve things to the point where 
we could make the block definition more precise by declaring 
prerequisites as part of the block spec based on the magic project 
dependency declarations.

Also - we are starting to get to the point where we have a reasonable 
amount of information about a particular component available to us. 
Given the graph of all projects contributing to a given project - its 
not unreasonable to determine automatically if a version bump is 
required.  In effect if there is a version change in any of the 
dependents then we have at least a micro version bump in this component. 
  We can probably go further and figure out if the version change is to 
our components api or implementation - etc. - etc.  Using the same 
information - there is a reasonably solid amount of information that 
could be used to automate the generation of documentation about the 
component.

Finally - I have a suspicion that with adoption of some specific 
policies in svn, chances are we would be able to track back and get 
release information and start thinking about tasks that handle release 
validation.

Cheers, Steve.

-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|


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