yesamer opened a new pull request, #3585:
URL: https://github.com/apache/incubator-kie-tools/pull/3585

   Kie-Issue: https://github.com/apache/incubator-kie-issues/issues/2288
   
   Related PRs
   - Drools: https://github.com/apache/incubator-kie-drools/pull/6686
   - Optaplanner: https://github.com/apache/incubator-kie-optaplanner/pull/3221
   - Kogito Runtimes: 
https://github.com/apache/incubator-kie-kogito-runtimes/pull/4270
   - Kogito Apps: https://github.com/apache/incubator-kie-kogito-apps/pull/2331
   - Kogito Examples: 
https://github.com/apache/incubator-kie-kogito-examples/pull/2210
   
   ### Why
   kie-tools does not build any Spring Boot application of its own, but it 
shares dependency-version baselines with the rest of the KIE stack through 
`packages/maven-base/pom.xml` (the Maven parent every kie-tools Maven module 
uses) and `packages/maven-base/not-reproducible-plugins.properties` (the 
reproducible-build floor that downstream Maven builds consume via 
`node_modules/@kie-tools/maven-base/`).
   
   Once the rest of the KIE stack moves to Spring Boot `4.0.5`, three things in 
kie-tools drift out of alignment and have to follow:
   
   1. **JUnit Jupiter / JUnit Platform.** Spring Boot 4 ships JUnit 6. 
kogito-runtimes' `kogito-dependencies-bom` and drools' `build-parent` now pin 
both Jupiter and Platform to `6.0.3` via `junit-bom`. kie-tools' `maven-base` 
was pinned at Jupiter `5.13.4` with no Platform pin. When a kie-tools Maven 
module (e.g. `extended-services-java`) builds against the upgraded kogito BOM, 
Jupiter `6.x` and Platform `1.x` end up on the same classpath and tests fail at 
discovery with `NoSuchMethodError: 
org.junit.platform.commons.util.CollectionUtils.toUnmodifiableList()`.
   2. **Tomcat embedded core.** Spring Boot 4 requires Tomcat 11 (Jakarta EE 
10). The CVE-override pin in kie-tools `maven-base` was still at Tomcat 
`10.1.54`; kogito-runtimes is on `11.0.20`.
   3. **commons-lang3.** Same CVE-override block in kie-tools was pinned at 
`3.18.0`; the rest of the stack is at `3.19.0`.
   
   This PR aligns those three pins, adds the matching `junit-bom` import and 
`junit-platform-{commons,engine,launcher}` dependency-management entries so 
Jupiter and Platform always travel together, and bumps the 
`spring-boot-maven-plugin` reproducible-build floor from `3.5.12` to `4.0.5`. 
It also bumps the pinned `kogito-apps` git ref in `packages/drools-and-kogito` 
to the SB-4 head of the kogito-apps PR so the `drools-and-kogito` install 
package (which clones drools / optaplanner / kogito-runtimes / kogito-apps from 
the configured forks and runs `mvn deploy`) builds against the SB-4 sources, 
not the previous main-branch SHA that still uses pre-SB-4 imports.
   
   ### Things to call out
   
   - **JUnit version drift is the load-bearing fix.** Without it, kie-tools' 
own Maven test packages fail at JUnit discovery when built against the upgraded 
kogito BOM. This is the only change that fixes a real build break; the other 
alignments are consistency hygiene.
   - **Tomcat 10 → 11 is a major version bump in a CVE-override pin.** The pin 
is still scoped to its CVE-override role (`tomcat-embed-core` only). Spring 
Boot 4 ships Tomcat 11 by default; this just removes the kie-tools-side 
downgrade.
   - **commons-lang3 `3.18.0` → `3.19.0` aligns with kogito-runtimes' BOM**, 
where the value lives as `version.org.apache.commons`. Same property name in 
kie-tools (`version.apache.commons.lang3`) — different name, same artifact.
   - **`packages/drools-and-kogito` SHA bump.** This package clones drools / 
optaplanner / kogito-runtimes / kogito-apps from the configured forks at the 
configured SHAs and runs `mvn deploy` to populate a local dist Maven repo. The 
kogito-apps SHA was at `46ebd650a` (last commit on main before the SB 4 work); 
bumping it to `ba8b1cdc8` (head of the kogito-apps SB-4 PR) lets the package 
build cleanly. The other three SHAs were already on their SB-4 heads.
   - **No source-code or pom.xml outside `packages/maven-base/` is touched.** 
Every other kie-tools pom either inherits from `kie-tools-maven-base` (so it 
picks up the new pins automatically) or stands alone with values that already 
match the canonical KIE stack 
(`packages/dev-deployment-quarkus-blank-app/pom.xml`).
   - **No Quarkus changes.** Quarkus stays at `3.27.3`, matching the rest of 
the stack.
   
   ### How to review
   
   - **`packages/maven-base/not-reproducible-plugins.properties`**: one-line 
floor bump for `spring-boot-maven-plugin` `3.5.12` → `4.0.5`. The trailing 
comment line still points at `spring-projects/spring-boot#21005`, the upstream 
issue that prompted adding the entry in the first place.
   - **`packages/maven-base/pom.xml`**: the version-property block in 
`<properties>` and the matching entries in `<dependencyManagement>`. Four 
changes here:
     - Replaced `version.org.junit.jupiter` (was `5.13.4`) with a single 
`version.org.junit` = `6.0.3` covering Jupiter, Platform, and Vintage via 
`junit-bom`. The naming matches drools `build-parent` and kogito-runtimes 
`kogito-dependencies-bom`: `version.junit` for JUnit 4 (groupId `junit`) and 
`version.org.junit` for JUnit 6 (groupId `org.junit.*`).
     - `version.tomcat.embed.core` `10.1.54` → `11.0.20` (matches 
kogito-runtimes)
     - `version.apache.commons.lang3` `3.18.0` → `3.19.0` (matches 
kogito-runtimes)
     - New `<dependencyManagement>` entries: `junit-bom` import, plus 
`junit-platform-commons / -engine / -launcher`, all referencing 
`${version.org.junit}`. These ensure Jupiter and Platform never drift apart on 
the classpath.
   
     ---
     
     NOTE: Needs to be updated the git ref after the other prs are merged


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to