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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
