Closed venetrius closed 3 months ago
Steps:
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.
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: https://github.com/camunda/camunda-bpm-platform/issues/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
/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
Neither updating wiremock or mockito passing the CI, created new issues: https://github.com/camunda/camunda-bpm-platform/issues/4384 https://github.com/camunda/camunda-bpm-platform/issues/4385
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.
This issue tracks multiple enhancements and questions related to dependency management across various modules of the Camunda BPM platform.
related to: https://github.com/camunda/camunda-bpm-platform/issues/3682
Spin - Unified Jakarta BOM Usage
Context: PR follow up
spin/dataformat-xml-dom-jakarta/pom.xml
❓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 uses4.0.2
version ofxml.bind-api
Simply bumping the version to latest or downgrading to2.3.3
causes the build to fail.Created a follow up task to have a single version of the lib: https://github.com/camunda/camunda-bpm-platform/issues/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
Spin - remove master branch from file-list
Context:
file-list
is used by internal toolsOutcome: 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 thecommons-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:
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: https://github.com/camunda/camunda-bpm-platform/issues/4385Connect 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: https://github.com/camunda/camunda-bpm-platform/issues/4384Freemarket-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
infreemarker-template-engine/pom.xml
to2.9.1
Breakdown