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:
- Changes the POM version from a development version to a release version
- Tags the codebase
- Performs a build
- Publishes the assets to the appropriate Maven repository
- 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:
- Open your client specification using the command: p4 client
- Under the View section, add a line like the following (using a depot path and client name appropriate to your configuration):
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, com.perforce.target.someClass), because material under the com/perforce/target directory will not be allowed to be added to Perforce.