Pomutils deals with POM trees. You can

• Run queries and/or operations on POM trees
• Generate root POMs to build only the required sub projects of a large project based on a build manifest
• Move common POM fragments into individual XML files, and maintain them

Querying and Modifying POM files

Querying a POM file

Prints the results of an XPath based on a POM file.

pomutil <pomfile> -xp<XPath>

Example:

Print out the version of a project:

pomutil pom.xml -xp/project/version

Check version number sanity accross POM files

Determines artifact cross references in a POM tree, and prints inconsistencies where a version of the artifact is built, but a different version of that artifact is referenced in another part of the tree.

pomutil <pomfile> -x

Print versions of all artifacts in a POM tree

Prints out all artifact names and versions

pomutil <pomfile> -p

Each artifact is written in a separate line with the following format:

groupId:artifactId=version

Change version number of an artifact in a POM tree

Changes the version number of an artifact in the POM file where it is defined, and in all POM files where it is referenced.

pomutil <pomfile> [-a] -vgroupId:artifactId:version

Sets the version number of groupId:artifact to version. The -a switch rewrites all poms. Without -a, only modified poms are written.

Bulk change version

pomutil <pomfile> -fFile

where File is a text file that uses the same format as the -p (print all versions) option.

You can print all versions of a project to a file, then edit that file to set new version numbers, and use this feature to set version numbers in bulk:

pomutil pom.xml -p>versions
# edit versions file to set the new version numbers
pomutil pom.xml -fversions

Find projects in a POM tree depending on an artifact

pomutil <pomfile> -dfgroupId:artifactId:version

Lists all the pom files in which groupId:artifactId:version appears as a direct dependency. version can be "*", meaning any matching groupId:artifactId will be listed.

Remove a direct dependency from a POM tree

pomutil <pomfile> -drgroupId:artifactId:version

Remove al occurances of groupId:artifactId:version from all projects in the tree. version can be "*".

Partial Builds

It is rarely necessary to build all modules of a large project containing many submodules. Pomutil can generate root POM files for such projects based on a build manifest listing the sub modules that need to be built. The generated POM file build all the modules given in the build manifest, and all the modules that depend on the modules in the build set.

Project structure

Consider an aggregator style root POM listing basic configuration and all the sub projects:

code/pom.xml:

<project>
  ...
   <modules>
      <module>module1</module>
      <module>module2</module>
       ...
      <module>moduleN</module>
   </modules>
  ...
</project>

Every build of this project requires that all the submodules module1,...,moduleN are also built. If our workset is limited to, say, only module1, it is not necessary to rebuild all submodules every time. What is required is that you build module1 to test/release your changes, and you build any module that depends on module1, so those can be release as well now that they are using a newer version of module1. To do this, a build manifest is prepared:

myworkset.xml:

<manifest>
   <buildset>
      <module>module1</module>
   </buildset>
</manifest>

We also need a definition of all the available modules:

all.mf.xml:

<manifest>
   <modulemap>
      <module>
         <name>module1</name>
         <pom>module1/pom.xml</pom>
      </module>
      <module>
         <name>module2</name>
         <pom>module2/pom.xml</pom>
      </module>
      ...
      <module>
         <name>moduleN</name>
         <pom>moduleN/pom.xml</pom>
      </module>
   </modulemap>
</manifest>

Last, we need to provide a skeleton POM file containing all the project related configuration we need at the root pom level:

skel.xml:

<project>
   <modelVersion>4.0.0.</modelVersion>
   <groupId>autogen</groupId>
   <artifactId>root</artifactId>
   <version>0</version>
   <packaging>pom</packaging>
   <name>autogen</name>
   <dependencies>
     ...
   </dependencies>
   <build>
     ...
   </build>
   <modules>
   </modules>
</project>

Note the empty modules element.

Then, running

pomutil -rmyworkset.xml -lall.mf.xml -opom.xml -sskel.xml

will generate a pom.xml file, using skel.xml as a baseline, adding all the modules listed in the build manifest and the modules that are dependent on that build set.

XMLFrag

Aggregator style Maven projects have some limitations. Most of the common project information is stored in the root pom, and child projects inherit from it. It is not possible to modularize such projects so that sligthly different configurations can be applied for certain targets. Inheriting from multiple root poms is not allowed, so sub projects end up overriding things setup in root pom.

Instead of using a root pom, a large project structure can be divided into individual smaller projects, with fragments of POM files are stored in a different location. XMLFrag reconstructs POM files using such fragments.

Move sections of POM files into fragments. For instance:

Original POM file:

<project>
   ...
   <dependencies>
     <dependency>
      ...
     </dependency>
   </dependencies>
   ...

Move dependencies to a fragment:

fragments/dependencies.frag.xml:

<fragment>
   <dependency> 
     ...
   <dependency>
</fragment>

POM file:

<project>
   ...
   <dependencies>
   <!--Fragment: dependencies.frag.xml-->
   </dependencies>
   ...
</project>

Then, run XMLFrag:

xmlfrag -ffragments pom.xml

This command inserts the contents of fragments/dependencies.frag.xml into the pom file. It also replaces the fragment comment with hash information, so that if the fragment is modified, the modifications are applied to the pom file correctly when xmlfrag is run again. If fragments inserted into the POM file using xmlfrag is manually modified, xmlfrag will warn when executed. -x switch forces replacement of the fragments in pom files.