Dependencies may be declared within <module>, <project>, and <resource> elements using the <dependencies> element. Resources may declare a single <dependencies> element representing the runtime dependencies of the resource. Projects may declare BUILD, RUNTIME and TEST scoped dependencies under respective element names.
| build | 0..1 | Declaration of build time dependencies group. When building multiple projects build time dependencies may be used to influence project build sequencing. Any resources referenced within the <build> element are gauranteed to be be built prior to the project referencing the dependency. |
| runtime | 0..1 | Declaration of runtime dependencies group. |
| test | 0..1 | Declaration of test dependencies group. |
| include | 0..n | Declaration of the inclusion of a reference to another resource, project or module. |
An <include> element may be declared uisng one or three variants.
| key | Refers to another resource or project within the same module as the declaring entity. The value of the key is the name of the project or resource. |
| <include key="[name]"/> | |
| ref | Refers to another resource or project via a fully qualified name. |
| <include ref="[group]/[name]"/> | |
| uri | Establishes an annonomous reference using the artifact uri to establish the group, name, version and type. |
| <include uri="[artifact]"/> |
Project includes within <runtime> scope may also qualify the inclusion relative to one of the tag values public, protected or private. Tagged includes are used in the construction of plugin metadata and are declared using the tag attribute. The public category is normally used to assert a dependency that is a part of the public API of a plugin. The protected category is normally used to associate a dependency such as a management API that is an extension of the public API. The default category value private represents a classloader category that extends the protected classloader and typically represents the internal implementation of a sub-system.
The following project definition uses a combination of all three include variants. Two dependencies (dpml-http-api and dpml-http-spi) use the short form local reference via the key attribute. Five includes reference resources or projects via fully qualified names, and a further seven includes use the uri notion.
<project name="dpml-http-impl" basedir="impl">
<types>
<type id="jar"/>
</types>
<dependencies>
<runtime>
<include ref="dpml/metro/dpml-metro-model"/>
<include ref="dpml/util/dpml-logging-api"/>
<include uri="artifact:jar:org/mortbay/servlet-api-2.5#20060213" tag="PUBLIC"/>
<include uri="artifact:jar:tomcat/jasper-runtime#5.5.12"/>
<include uri="artifact:jar:tomcat/jasper-compiler#5.5.12"/>
<include uri="artifact:jar:tomcat/jasper-compiler-jdt#5.5.12"/>
<include uri="artifact:jar:org/mortbay/jetty#20060213"/>
<include uri="artifact:jar:org/slf4j/jcl104-over-slf4j#1.0-rc5"/>
<include uri="artifact:jar:org/slf4j/slf4j-jdk14#1.0-rc5"/>
<include uri="artifact:jar:commons-el/commons-el#1.0"/>
<include ref="dpml/transit/dpml-transit-main"/>
</runtime>
</dependencies>
</project>
The following example demonstrates the separation of test versus runtime dependencies.
<project name="dpml-metro-model" basedir="model">
<types>
<type id="jar"/>
</types>
<dependencies>
<runtime>
<include key="dpml-state-api"/>
<include key="dpml-metro-component"/>
</runtime>
<test>
<include ref="ant/ant-junit"/>
<include key="dpml-state-impl"/>
</test>
</dependencies>
<filters>
<feature token="NAME" id="name"/>
<feature token="VERSION" id="version"/>
<feature token="GROUP" id="group"/>
<feature token="PART-HANDLER-URI" id="uri" ref="dpml/metro/dpml-metro-runtime" type="part"/>
</filters>
</project>