Maven 3.4.0 may break ImageJ and Fiji project builds

Just a heads up that Maven 3.4.0 (not yet released) currently has problematic behavior with respect to ImageJ and Fiji component builds. See these links for details:

The two main problems with Maven 3.4.0 are:

  1. You can no longer override managed version properties in your POM’s <properties> section.
  2. Building previous release tags of Fiji and other complex SciJava-based components will no longer produce the same dependency trees as with Maven 3.3.x and earlier.

I have registered my concerns with these changes upstream, but it seems likely that the changes will not be reverted. So let this serve as a warning:

  • The details of how we manage SciJava component versions will need to change.
  • Expect broken builds if you adopt Maven 3.4.0 when it is released.
  • Stay away from Maven 3.4.0 until we sort out how to proceed.
3 Likes

An update on this issue for those interested: the discussion is still ongoing in the Maven user + dev communities. For full details, you can browse the thread by looking at the “Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)” and “POM Model version 4.1.0 in 3.4.0-SNAPSHOTs” threads in the August 2016 maven-users archives.

A short summary so far:

  • Lots of work has been done by one of the main committers (Christian Schulte) to try to reconcile the needs of various projects, including SciJava, Spring Boot and others.
  • There is concern amongst some of the other main committers (e.g., Robert Scholte) that the current approach of increasing the POM model version from 4.0.0 to 4.1.0 will wreak havoc downstream somehow.
  • One proposed solution is to introduce a new scope called include which is similar to import but resolves dependencies in a better (but backwards incompatible) way.
  • Therefore, it is not clear what is going to happen with Maven 3.4.0—it might break our old builds, or it might not. I have argued on the list for Maven to maintain backwards compatibility, while finding a way forward that improves behavior in the future. Either the 4.1.0 model version change or the new include scope would accomplish those goals.

Regardless of the ultimate resolution, the discussion has made it clear to me that we need to separate our Bill of Materials POMs from our parent POMs. I will start a separate thread about this now.