Using Maven (http://maven.apache.org/) for dependency management frees developers from having to manually download and manage third-party dependencies. This greatly simplifies the process of upgrading third-party libraries and gives developers more time to work on actual development. Maven provides a number of features to simplify dependency management. The core concept is the idea of project object model files (poms). Poms are a standardized way to describe a project: group, artifact, name, version, dependencies, layout, etc.

Inheritance of Dependency Versions

Versions of third-party libraries can be specified in a high-level/parent pom. This allows subprojects that need a certain dependency to leave the version empty and use the one specified in the parent. Upgrading all projects to use a newer third-party library is as simple as changing one version number in the parent pom.

Transitive Dependencies

Since each dependency specifies its own dependencies, only direct dependencies of a project need to be specified. Any other runtime dependencies of those dependencies will be included automatically. i.e. If project A specifies B as a dependency and B requires C and D to run, then A will automatically get B, C, and D.

Dependency Fetching

Maven also includes automatic downloading and caching of dependencies. As new dependencies are required during the build process, Maven will check for a local copy. If there is no local copy, Maven will automatically download it.

In order to move from Antlion to Maven, we need to make a number of changes in our build scripts and configuration files:

• The old jars.xml file has been removed and replaced by a dependency management section in our top-level pom, elasticpath.pom
• All of the per-project dependency listings in the artifact.xml files have been removed and placed in pom.xml files within each project

For the most part, developers do not need to know much about Maven; it operates transparently behind Ant. However, when you need to change or add dependencies, some knowledge of the setup is required.

At Elastic Path, we have an internal Maven repository, managed by an instance of Archiva (http://archiva.apache.org). It not only provides a place to keep custom/missing dependencies, but also acts as a proxy to various public Maven repositories. If a newly added dependency is available in the public repositories, it will be automatically fetched and cached by Archiva.

Adding New jars

When a dependency cannot be found in any public repositories, or when a dependency has been patched or customized, it will need to be manually deployed to Archiva. At present, this requires Maven to actually be installed on the computer doing the deployment. Then the following steps need to be performed.

1. Create a pom for the jar if none exists. If the jar was patched or customized, append something to the version to indicate this (ex. 2.5.5-clientA-projectX-1.0).

2. Choose the repository to deploy to:

• Internal - artifacts available from public Maven repositories.
• Extras - artifacts not found in a Maven repository.
• Custom - open-source libraries that have been patched or customized.
• Restricted - libraries that are not redistributable, but are required internally during development and testing.
• Other - if you are working on a project that is customizing the EP platform you should probably have a repository (or repositories) created specifically for your project which will make it easier to tell which libraries you need to redistribute.

3. Edit ~/.m2/repository/settings.xml file to specify your Archiva username and password.

<servers>
<server>
 <id>deployment.webdav</id>
 <username>{archiva-deployment-user}</username>
 <password>{archiva-deployment-pwd}</password>
</server>
</servers>

4. Create a new folder from where you will deploy the jar and create a pom there with the following content:

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>webdav-deploy</artifactId>
<packaging>pom</packaging>
<version>1</version>
<name>Webdav Deployment POM</name>

<build>
 <extensions>
 <extension>
 <groupId>org.apache.maven.wagon</groupId>
 <artifactId>wagon-webdav</artifactId>
 <version>1.0-beta-2</version>
 </extension>
 </extensions>
</build>
</project>

5. Navigate on the command line to the folder created in the previous step and run the following command.

mvn deploy:deploy-file -Dfile=filename.jar -DpomFile=filename.pom

-DrepositoryId=deployment.webdav

-Durl=dav:http://maven.elasticpath.net/archiva/repository/{repository}

Setting up a Project

To set up a new project, you need to create a pom file.

1. Copy an existing pom to use as a starting point (com.elasticpath.cm/pom.xml for a new web project or com.elasticpath.ql/pom.xml for a jar).

2. Modify the artifactId, packaging, name, and description to reflect the new project.

3. Leave the parent section alone as it will allow you to inherit settings from the main EP pom.

4. Remove all the dependencies that are not required, and add any new ones that are needed.

5. Review the build section and modify the directories as required.

Since we are still using Ant to do the actual building, the build.xml and artifact.xml files will also have to be created. Copy and modify existing ones from the project you copied the pom from.

Using Proper pom Versions

If any modifications are made to an existing project, make sure to open the pom.xml and modify the version string. If there is no version setting, the project was inheriting the parent pom's version and one will have to be added. During active development the version string for a new or modified project should be something like 6.1-clientA-projectX-SNAPSHOT. For each release the version should be changed to something like 6.1-clientA-projectX-1.0 and then ...-1.1, ...-1.2, etc. This tells anyone looking at it exactly which EP release it was based on and for which client/project it was for.