Perforce Public Knowledge Base - Maven Integration
Reset Search



Maven Integration

« Go Back



This article provides an overview of using Maven with Perforce.


Introduction to Maven with Perforce

The online book Maven: The Definitive Guide describes Maven as "a project management tool which encompasses a project object model, a set of standards, a project lifecycle, a dependency management system, and logic for executing plugin goals at defined phases in a lifecycle."

You describe your project in Maven with an XML-based Project Object Model (POM). Maven then uses this POM to apply cross-cutting logic from a set of plugins.

For more details on Maven, see:

Integration with Perforce

Maven has a component called Maven SCM that provides a common API to perform SCM operations. Perforce is one of the SCMs that has been implemented.

For more details on Maven SCM and the implementation for Perforce, see:

Using Maven with Perforce

Branching and the Maven POM Version

Each Maven Project Object Model (POM) has has an associated version. The version is used along with the name of an asset to generate a Maven coordinate, or unique identifier for that asset at that version. The version is set in pom.xml, using the <version> element.

Because this version is used to create a unique identifier, you must change the Maven POM version when branching in order to avoid collisions in Maven's coordinate space. In addition, when merging changes between branches, care must be taken to resolve the POM <version> element appropriately.



Perforce Considerations for a Maven Release

To perform a Maven release, the Maven Release plug-in:

  1. Changes the POM version from a development version to a release version
  2. Tags the codebase
  3. Performs a build
  4. Publishes the assets to the appropriate Maven repository
  5. Changes the version back to a development version

In tagging the codebase, a static label is created and files in the current workspace are tagged appropriately. The Maven SCM Perforce integration is not aware of dynamic/automatic labels. If dynamic/automatic labels are desired, logic must be written to convert the static labels into dynamic labels, post-release. Logic should also be written to verify that what is being released is aligned to a changelist.

A side-effect of the release process is that two changelists are created as part of a release: one changelist to capture the release version, which is tagged, and another changelist to revert the source back to the development version. As described in the previous section, extra care must be taken to ensure the value of the POM's <version> element is not propagated inappropriately when branching.


Excluding target hierarchies from Perforce

Maven deposits all intermediate and final build artifacts under a directory named target. You can easily exclude this path from being accidentally added to Perforce through a client exclusionary mapping:

  1. Open your client specification using the command: p4 client
  2. Under the View section, add a line like the following (using a depot path and client name appropriate to your configuration):
    -//depot/.../target/... //myclient/.../target/...
  • Save and exit

With the above view mapping, if you try to add a file from a target directory to Perforce, you receive the error message: no permission for operation on file(s). This effectively keeps target directory contents out of Perforce.

Note: You must ensure that the name "target" is not used as any part of your Java packaging hierarchy (for example,, because material under the com/perforce/target directory will not be allowed to be added to Perforce.

Related Links



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255