In Java-land, it’s still extremely common for problems to be solved by application of XML. Nowhere is this more true than in Java build processes, which is where Maven and its infamous POM.xml file come into play.

Maven is an opinionated build framework- it requires that your project fit into a certain pattern. It’s also fiendishly complex. It also has some surprising guns with which you can target your own foot.

Bret G saw builds suddenly start failing. Well, not failing, per se, but just not finishing. Sometimes the build would just hang. Sometimes it would crash with an out-of-memory error. Sometimes they’d get “Garbage collector timeout” messages, which is certainly a novel and rare error to see.

This particular repo didn’t have the cleanest commit history. Multiple teams working on multiple deployables and their dependencies across piles of branches meant everything in source control was complicated. There were lots of commits. Some commits were arguably larger than they should really be, including multiple changes. Some were extremely large. Combined with no clear source of the error, Bret had to spend a lot of time tracking down the cause of the error, which was in the commons-logging POM.xml file.

<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">
    - Note that due to the special requirements of logging unit-tests, most
    - tests are executed in the "integration-test" phase rather than the
    - "test" phase. Please run "mvn integration-test" to run the full suite of
    - available unit tests.
  <name>Commons Logging</name>

Apache’s commons-logging library is a common dependency to use in a Java project. For various reasons, Bret’s organization tweaked the POM for the library to change how it integrated into their project. Take a look at the parent element though, which defines what is, essentially, inheritance in POM files.

This says that the commons-logging POM said that it inherited off the commons-logging POM.

In the end, the commit was tracked back to the responsible party. Chastisings were handed out. Root cause analyses were run. Management, in the interests of “doing something, ANYTHING” wrote policy documents and send emails and scheduled meetings.

More practically, the next time the builds start crashing, Bret has a much better idea of what to look for.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!