Make codebase ready for latest Maven version

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-11822
Reporter	@ThorbenLindhauer
Has restricted visibility comments	true

---

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

Breakdown

• [x] Have solution for javax.activation
• [x] Compare artifacts with different versions

We know the changes that has to be applied to

• [x] https://github.com/camunda/camunda-bpm-platform
• [x] https://github.com/camunda/camunda-bpm-platform-ee
• [x] https://github.com/camunda/cambpm-jenkins-shared-library

Jenkins instances use the latest Maven version

• [x] ci-pipeline
• [x] ci.cambpm
• [x] release

Links:

• is depended on by https://jira.camunda.com/browse/CAM-12396
• Doc: https://docs.google.com/document/d/1MBDHfOSnbeCTeztBM0T9DgLt0QxtCyZ1A-TnpRXOADE

[yanavasileva]

After execution of the ci with Maven 3.8 the only problem detected is addition library dependency to javax.activation to the following artifacts:

• camunda-wildfly-modules-7.19.0-SNAPSHOT.jar
• camunda-qa-performance-tests-engine-7.19.0-SNAPSHOT.jar
• camunda-engine-feel-juel-7.19.0-SNAPSHOT.jar
• camunda-engine-7.19.0-SNAPSHOT.jar
• camunda-bpm-run-core-7.19.0-SNAPSHOT.jar
• camunda-wildfly-assembly-7.19.0-SNAPSHOT.tar.gz
• camunda-bpm-wildfly-7.19.0-SNAPSHOT.tar.gz
• camunda-bpm-ee-wildfly-7.19.0-SNAPSHOT.tar.gz
• camunda-webapp-ee-wls-standalone-7.19.0-SNAPSHOT.war
• camunda-webapp-ee-was9-standalone-7.19.0-SNAPSHOT.war
• camunda-webapp-tomcat-standalone-7.19.0-SNAPSHOT.war
• camunda-webapp-ee-tomcat-standalone-7.19.0-SNAPSHOT.war
• camunda-webapp-ee-was-standalone-7.19.0-SNAPSHOT.war
• camunda-webapp-jboss-standalone-7.19.0-SNAPSHOT.war
• camunda-webapp-ee-jboss-standalone-7.19.0-SNAPSHOT.war
• camunda-bpm-wildfly-7.19.0-SNAPSHOT.zip
• camunda-bpm-ee-wildfly-7.19.0-SNAPSHOT.zip

The problem is occurs at least at two places with Maven 3.8 (including Maven >= 3.3):

• incorrectly shade the transitive dependencies to other artifacts.

• after the packaging, a maven-dependency-plugin lists the dependencies including javax.activation, gets populated in dependencies-generated.txt, then repackages the artifacts with the listed dependencies

  The issue is reported to Maven, but for several years no solution is provided.

[tasso94]

I did a little more brainstorming and came up with some more ideas we could investigate:

• Might the dependency scope of javax.activation influence whether the dependency is further propagated in the Maven Reactor? Maybe we can create a situation that allows shading in typed-values, but due to the dependency scope of javax.activation, the shading plugins in downstream projects of the reactor don't take it further into account
• Can we create a "workaround" Maven project that depends on typed-values but excludes javax.activiation? The downstream projects would depend on this "workaround" Maven project
• We could remove the shading from typed-values and do it only where it is necessary (like the engine shading plugin); didn't think it through: do people use typed-values artifact directly in their projects?
• We could move typed-values back to camunda-commons

[yanavasileva]

Decided: define javax.activation as optional dependency in typed-values. The dependency is not propagated to the other artifacts that have dependency to typed-values. So the change is made only for the typed-values and other adjustments are required in the code.

[yanavasileva]

The many PRs are for data collection, I will not close them so far. For review, PRs to make codebase ready:

• https://github.com/camunda/camunda-bpm-platform/pull/2855
• https://github.com/camunda/cambpm-jenkins-shared-library/pull/94