In the CI we currently use Maven 3.2 to build our artifacts. From a maintenance perspective, it is important to update the Maven version at some point so that we can benefit from new features and fixes in Maven, e.g. using Maven plugins that require a certain minimal version.

—

We can move to a newer version, but must do this carefully. This ticket's goal is to prepare our codebase for a newer Maven version. Many devs already use newer versions locally and it's generally fine, but there may be some very non-obvious details that can change with newer Maven versions. We can collect such things in this ticket.

AC:

• The Maven version we want to support is decided (e.g. latest; latest offered by Infra; ...)
• Our entire codebase builds correctly with this Maven version (i.e. the resulting artifacts are the same; the CI coverage is the same and not impacted)
• To be decided: Our CI runs on this Maven version (can also be a separate ticket)

Problem 1:

• Using Maven shade plugin to shade a library into a JAR. Consuming that shaded JAR in the same Maven reactor with another module.
  • Behavior with Maven 3.2: When resolving dependencies, Maven respects the dependency-reduced-pom.xml created by Maven shade. That means, shaded libraries are not propagated as transitive dependencies.
  • Behavior with Maven >= 3.3: This does not work anymore (a regression). The consuming module receives the shaded library as a transitive dependency as well.
  • Impact: e.g., we incorrectly shade these transitive dependencies to other artifacts. E.g. feel-scala then also shades javax.activation (but without relocation, so it pollutes the user classpath)
  • Way to check this: Run mvn -pl engine-dmn/feel-scala -am dependency:tree in the platform repo. This creates a multi-module build that includes commons-typed values and feel-scala-api. typed-values shades javax.activation. With Maven 3.2, we can see that javax.activation is not a transitive dependency in any module that consumes typed-values. With higher Maven versions, it is.
  • Possible workarounds: Exclude the transitive dependencies wherever they are consumed in the same project. As our release build is one gigantic multi-module build (ee and core platform), this may span multiple repositories.
  • Related resources
    • https://issues.apache.org/jira/browse/MSHADE-206
    • https://issues.apache.org/jira/browse/MNG-5899

See also https://confluence.camunda.com/display/AP/Maven+3.2