Consolidate upstream/downstream libraries - follow ups

[venetrius]

This issue tracks multiple enhancements and questions related to dependency management across various modules of the Camunda BPM platform.

related to: #3682

Spin - Unified Jakarta BOM Usage

Context: PR follow up

spin/dataformat-xml-dom-jakarta/pom.xml

  <dependency>
      <groupId>jakarta.xml.bind</groupId>
      <artifactId>jakarta.xml.bind-api</artifactId>
      <version>${version.jakarta.xml.bind-api}</version>

❓Instead of a separate versioning, could we maybe also use the jakarta.jakartaee-bom here? That's already defined and used at several other places so it could be easier for future updates.

Outcome:

Platform uses 2.3.3 camunda-spin-dataformat-xml-dom-jakarta uses 4.0.2 version of xml.bind-api Simply bumping the version to latest or downgrading to 2.3.3 causes the build to fail.

Created a follow up task to have a single version of the lib: #4383

Spin - update scm tag

Outcome: updated spin/bom/pom.xml & spin/pom.xml

Context:

SCM tag points to the old repository which could be an issue in the CI

  <scm>
    <url>https://github.com/camunda/camunda-spin</url>
    <connection>scm:git:git@github.com:camunda/camunda-spin.git</connection>
    <developerConnection>scm:git:git@github.com:camunda/camunda-spin.git</developerConnection>
    <tag>HEAD</tag>
  </scm>

• also remove master branch-es from https://github.com/camunda/camunda-bpm-helper-resources/blob/master/notice-file-update/file-list

Spin - remove master branch from file-list

Context: file-list is used by internal tools

Outcome: Updated

Commons - update SCM tag

same context and outcome as for Spin

Commons - remove master branch from helpers repo

same context and outcome as for Spin

Commons - Package typed-values with commons-bom

Context: Typed values have been moved under ./commons but not packaged with the commons-bom yet. This can cause confusion during maintenance.

Outcome: Packaged typed-values within commons-bom

Commons - Use the platform defined version variable for Logback

Context: Logback version is hardcoded in commons/pom.xml which make maintenance more complicated.

Outcome: Update commons/pom.xml to use ${version.logback}

Commons - Readme - Check & Update required Java version

Outcome: Readme was outdated updated readme to correctly state:

Java JRE 1.8+ is required.

Connect uses wiremock 1.58 while platform uses 2.27

Context: having multiple version of the same library increases maintenance effort.

Outcome: CI fails when bumping wiremock. Created follow up task: #4385

Connect uses mockito 1.9.5 while platform uses 5.10.0

Context: having multiple version of the same library increases maintenance effort.

Outcome: CI fails when bumping mockito . Created follow up task: #4384

Freemarket-template-engine uses assertj-core 3.20.2 while platform uses 2.9.1

Context: having multiple version of the same library increases maintenance effort.

Outcome:

Build fails if assertj-core is bumpied up
Downgraded assertj-core in freemarker-template-engine/pom.xml to 2.9.1

Breakdown

Pull Requests

Beta Give feedback

1. chore(project): consolidate libs follow ups #4377
   ci:all-as +1
   
2. https://github.com/camunda/camunda-bpm-helper-resources/pull/9
3. https://github.com/camunda/camunda-bpm-platform-ee/pull/936
4. chore(freemarker-template-engine): downgrade assertj-core #4394
   ci:all-as +1
   

[venetrius]

Steps:

• (created task) Spin - could we use the existing jakarta.jakartaee-bom versioning instead of jakarta.xml.bind-api
• Spin - update scm tag
• Spin - remove master branch from helpers repo
• Commons - update scm tag
• Commons - remove master branch from helpers repo
• Commons - Readme - Check & Update required Java version
• Commons - Package typed-values with commons-bom (need to be mentioned in migration guide?)
• Commons - Use the platform defined version variable for Logback
• (created task) Connect uses wiremock 1.58 while platform uses 2.27
• (created task) Connect uses mockito 1.9.5 while platform uses 5.10.0
• Freemarket-template-engine uses assertj-core 3.20.2 while platform uses 2.9.1

[venetrius]

Commons - [Readme] - Check & Update required Java version (Java 11?)

Required version is correct, it was specified in .ci.cambpm but file has been removed during reconciliation.

Based on docs: https://docs.camunda.org/manual/7.20/introduction/supported-environments/ supported minimum is Java 11, updated the Readme file.

[venetrius]

Spin - could we use the existing jakarta.jakartaee-bom versioning instead of jakarta.xml.bind-api

PR follow up:
spin/dataformat-xml-dom-jakarta/pom.xml

  <dependency>
      <groupId>jakarta.xml.bind</groupId>
      <artifactId>jakarta.xml.bind-api</artifactId>
      <version>${version.jakarta.xml.bind-api}</version>

❓Instead of a separate versioning, could we maybe also use the jakarta.jakartaee-bom here? That's already defined and used at several other places so it could be easier for future updates.

Platform declares <version.xml.bind-api>2.3.3</version.xml.bind-api> but camunda-spin-dataformat-xml-dom-jakarta uses 4.0.2.

Created a follow up task to have a single version of the lib:
#4383

[jangalinski]

+1 for keeping the declared versions in sync (e.g. include them in the camunda-bom)
-1 for using jakartaee-bom - as a spring boot user, this might conflict with versions declared in spring-boot-bom

[venetrius]

Freemarket-template-engine uses assertj-core 3.20.2 while platform uses 2.9.1

Bumping platform assertj-core up to 3.20.2 (or to latest 3.26.0) fails with:

/engine-dmn/engine/src/test/java/org/camunda/bpm/dmn/engine/test/asserts/DmnDecisionTableResultAssert.java:[23,8]
org.camunda.bpm.dmn.engine.test.asserts.DmnDecisionTableResultAssert is not abstract and 
does not override abstract method 
newAbstractIterableAssert(java.lang.Iterable<?
 extends org.camunda.bpm.dmn.engine.DmnDecisionRuleResult>) 
in org.assertj.core.api.AbstractIterableAssert

Downgrading Freemarket-template-engine to 2.9.1 (that is used by platform) build work pushed changes to branch

[venetrius]

Connect uses wiremock 1.58 while platform uses 2.27 & uses mockito 1.9.5 while platform uses 5.10.0

Neither updating wiremock or mockito passing the CI,
created new issues:
#4384
#4385

[mboskamp]

Hi @venetrius, I reviewed the linked PRs. All the changes you made make sense to me. 👍

❌However, I find it hard to understand the exact goals of this issue. I can not understand what needs to be done from the issue description and why, making it impossible to assess if all tasks are completed. It would help to give the issue description more structure. For example, for each task, you can link sources (review feedback, test failures, etc.), describe the problem, and document your decision.

❓ I looked at this list. Does this list include all the TODOs for this issue? The PRs seem to tick all the boxes.
❓ However, there is one open question in the list: Package typed-values with commons-bom—migration guide? Do we need to change the migration guide?

❌You created follow-up issues (#4384 and #4385). When you create new issues, you should ideally pick one of the templates (bug report, task, etc.) and provide the information requested by the template. This would also have helped create a good description for this issue.

[venetrius]

Hi @mboskamp,
Thanks for your review. I update the issue description to make it easier to understand.
I think my learning here is that I shouldn't put too many goals in a single issue. In a future I will break issues down smaller tasks even is the code changes are relatively small.

I will reach out offline to discuss the other points.