This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Improved Ant Integration
Skip to end of metadata
Go to start of metadata

This page is a proposal for better integration between Ant and Maven.

Background

There are currently two commonly used tools for this are the Maven Ant tasks (using Maven from an Ant Build) and the Maven antrun plugin (using Ant from a Maven build). In addition there is a new dependency resolution API called Aether which will be available soon and this will likely provide new Ant tasks which allow the use of a Maven repository.

Use Cases - Ant Tasks

This section documents some common use cases related to Maven/Ant integration

A1 - Resolving Dependencies

Ant Tasks - Ant builds that use dependencies from a Maven repository need to be able to download the dependencies and access the downloaded artifacts via Ant properties, filesets, and/or other Ant types.

A1.1 - Configure Repositories

Adding repositories, authentication, proxies etc. is necessary for dependency resolution so these should be part of the API

A2 - Read POMs

The Ant tasks should have a way to read an existing POM and extract dependency information and other project configuration info.

A3 - Generate POMs

While not absolutely required (POMs could be hand edited), this could be very useful for doing things like collapsing a version range or resolving properties before deployment.

A4 - Deploying to a Maven Repository

The Ant tasks should be able to deploy artifacts to a Maven repository using the same underlying logic used by a Maven build.

Use Cases - Maven Antrun Plugin

This section describes common use cases for the antrun plugin.

M1 - Calling the Ant build

The first step is to start a valid Ant build, obviously nothing else works unless this happens. Ideally, the Ant build is as isolated as possible from the Maven build (i.e. separate classpath)

M2 - Sharing POM information

Information from the POM such as project name, version, properties etc needs to be availble to the Ant build. The Ant build should be able to easily access all information contained in the POM.

M3 - Sharing dependency information

(Related to requirement A1) The dependencies are resolved by Maven and downloaded to the local repository. The Ant build should be able to access individual dependencies or the entire dependency tree. The Ant build should also be able to perform operations on the set of dependencies, such as copying and filtering these files and possibly removing the version string from the filename.

Design Proposals

This section contains ideas for improving the integration between Maven and Ant

Proposal - Synching the maven-antrun-plugin with the Maven Ant tasks

There is currently not much in common between the maven-antrun-plugin and the Maven Ant tasks as far as the features and the way they work. This means that learning how to use one does not help learning how to use the other, and there is duplication of code between the two tools (for example resolving the dependency artifacts to properties). One idea is that these two tools could be combined/synched if the Ant tasks were changed in certain ways to be used as a dependency of the antrun plugin. The Ant tasks would work similar to the way they work currently, although there would be two different artifacts. The first would be a standalone jar which includes all the necessary dependencies to be used in an Ant build. The second artifact would include just the Ant tasks and could be used in an antrun plugin execution. This jar would have access to the current Maven classpath and therefore doesn't need to repackage the Maven libs.

The advantages of this design are:

  • There would be a single common integration API via the Maven Ant Tasks
  • New features added to the Ant Tasks would be available to the antrun plugin without duplicating code
  • The antrun plugin could remain very simple and focus on starting an Ant build and initializing the Maven tasks. Instead of adding new plugin parameters for each new features.

The disadvantages are:

  • New features released in the Ant tasks would not be available until a new release of the antrun plugin (unless possibly the user adds a plugin dependency with the newer version).
  • Some of the current Ant Tasks and antrun plugin features would be broken. So this would require a gradual merge process as features replaced and deprecated.

Examples

This section provides some examples of what the tasks could look like.

Initialize dependency properties and attaching an artifact to the build.
<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>xxx</version>
  <configuration>
    <tasks>
      <mvn:dependencyProps/>
      <mvn:attach file="target/my-extra-file.jar" classifier="extra"/>
    </tasks>
  <configuration>
</plugin>

The same steps in an Ant build with available pom.

<target name="deploy">
  <mvn:pom id="myproject" file="pom.xml"/>
  <mvn:dependencyProps projectRef="myproject"/>
  <mvn:attach file="target/my-extra-file.jar" classifier="extra"/>
  <mvn:deploy projectRef="myproject" url="file:///home/repository"/>
</target>

The same steps in an Ant build without a pom.

<target name="deploy">
  <mvn:pom id="myproject">
    <groupId>org.acme</groupId>
    <artifactId>foo</artifactId>
    <version>1.0</version>
  </mvn:pom>
  <mvn:dependencyProps projectRef="myproject"/>
  <mvn:attach file="target/my-extra-file.jar" classifier="extra"/>
  <mvn:deploy projectRef="myproject" url="file:///home/repository"/>
</target>

Roadmap

???

  • No labels

1 Comment

  1. Giving the Ant Tasks unlimited access to the classes from the underlying Maven runtime as already done by the AntRun Plugin, makes the Ant Tasks fragile (http://jira.codehaus.org/browse/MANTTASKS-165).