Consolidate upstream/downstream libraries - follow ups
venetrius opened this issue · comments
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
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
- Commons - Update Docs: Packaged typed-values with commons-bom
- 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
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.
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
+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
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
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.
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.
Resolved questions about the follow up tasks
Created PR to update migration guide regarding managing typed-values version via camunda-commons-bom
All subtask are done, closing this issue.
@gbetances089 no functional changes were introduced in this issue.