Using Dependency Information at Runtime via Plugins
Using Dependency Information at Runtime
Tutorial Objective

Given the availability of full dependency information from the Depot environment - the potential exists to capture the runtime related concerns and use this information to create a plugin definition sufficient for the automatic deployment of a application. This requires the capture of classpath information and the object deployment strategy.

This tutorial demonstrates the creation of a plugin using a simple constructor injection model and the subsequent deployment of an instance of SimpleClock using only the plugin defintion i.e. no references to implementation classes).


Our index.xml file has been updated to include a part:plugin production staement. The statement is declaring that the SimpleClock class is the deployment target and that two constructor arguments are to be provided on instantiation (a locale value and a format argument).

<?xml version="1.0" encoding="ISO-8859-1"?>
<index xmlns="dpml:library">

    <import uri="link:module:org/apache/ant"/>
    <import uri="link:module:dpml"/>

  <module name="org/acme/plugin" basedir=".">
      <type id="module" version="1.0">
    <project name="clock-api" basedir="api">
        <type id="jar"/>
    <project name="clock-impl" basedir="impl">
        <type id="jar"/>
        <type id="part" source="etc/component.xml"/>
          <include key="clock-api"/>
          <include ref="org/apache/ant/ant-junit"/>
          <include ref="dpml/transit/dpml-transit-main"/>

The Part Artifact

During the build the following part defintion is created based on the depolyment strategy input resource from the source data.

Generated part: artifact:part:org/acme/plugin/clock-impl#SNAPSHOT

<?xml version="1.0"?>

<part xmlns="dpml:part"


  <component xmlns="dpml:metro" type="org.acme.impl.SimpleClock">
      <entry key="format" value="h:mm"/>
      <entry key="locale" class="java.util.Locale" method="getDefault"/>



It contains the following data:

  • An information block.
  • A deployment strategy.
  • A classpath definition.

Collectively this information is sufficient to meet requirements of automated plugin deployment. In the following code example we demonstrate the construction of a Clock instance using the part artifact:

URI uri = new Uri( "artifact:part:org/acme/plugin/clock-impl#SNAPSHOT" );
URL url = uri.toURL();
Clock clock = (Clock) url.getContent( new Class[]{ Clock.class } );
String timestamp = clock.getTimestamp();

Two import considerations within the above code include:

  • no direct reference to a physical resource location (i.e. the artifact resource identifier addresses the development concern and the actual resource location and retrieval mechanism are not something that we as developer need be concerned with)
  • the code handling instance instantiation is not polluted with details concerning deployment strategy - in fact we could easily substitute a more sophisticated deployment models without any impact to the client code

However, the plugin strategy demonstrated above is for all intensive purposes a relatively primitive model in that it does not address real-world semantic issues such as lifecycle or lifestyle management, composition, thread-safety, remote management, or collection policies. The Metro Tutorials takes you into another semantic dimension with the introduction of an alternative deployment strategy based on the Metro Component Model whereas the final tutorial in the Depot collection wraps-up with project versioning management techniques.