BE: Chore: Bump Spring Boot to 3.5.3 #1143
Conversation
kapybro
bot
added
status/triage
yeikel
force-pushed
the
patch-2
branch
7 times, most recently
from
9a741e6 to
40076e3
Compare
| @@ -21,7 +21,6 @@ lombok = '1.18.34' | |||
| odd-oddrn-generator = '0.1.17' | |||
| odd-oddrn-client = '0.1.41' | |||
| cel = '0.3.0' | |||
| junit = '5.11.2' | |||
| mockito = '5.16.0' | |||
There was a problem hiding this comment.
JUnit 5, in particular, was causing a direct conflict that might be resolved by upgrading or aligning versions. However, since it’s brought in transitively by one our direct test dependencies, maintaining version alignment doesn't seem worth pursuing.
Mockit and assertj are also included transitively and technically falls into the same category, but it didn’t cause any issues during this upgrade.
Overall, reducing the number of explicitly managed dependencies isn’t a bad idea, so I’m open to removing them as well.
@Haarolean What do you think?
There was a problem hiding this comment.
I don't think it's a good idea to use some random junit/mockito versions pulled transitively. Bumping some other unrelated dependency then can break things, and junit is kinda known for breaking things sometimes.
There was a problem hiding this comment.
Do you suggest that we continue to sync them? Because what motivated this change is to align them with what Spring boot Uses as it was failing due to a conflict
There was a problem hiding this comment.
I'd align them (explicitly) with whatever spring boot uses itself, so in this case we'd have the same issues like we have now (version mismatch) rather than suddenly failing tests (say, when spring boot is bumped next time). What do you think?
| runtimeOnly(libs.micrometer.registry.prometheus){ | ||
| exclude group: 'com.google.protobuf', module: 'protobuf-java' because("Micrometer uses protobuf-java 4.x, which is incompatible with protobuf-java 3.x used by various dependencies of this project. See https://github.com/prometheus/client_java/issues/1431") | ||
| } |
There was a problem hiding this comment.
This may cause issues for anyone using this functionality, but there does not seem to be a clear fix for this other than prometheus/client_java#1431
None of our tests seem to be flagging this right now but it may be a matter of coverage
@Haarolean What do you think?
There was a problem hiding this comment.
For now, I pushed b57acf5 which we can revert as needed
There was a problem hiding this comment.
Yeah I doubt we have tests for this. However we should have a docker-compose somewhere in documentation/compose to try it out with prometheus.
Haarolean
added
scope/backend
yeikel
force-pushed
the
patch-2
branch
6 times, most recently
from
ad84806 to
c6a1568
Compare
What changes did you make? (Give an overview)
3.5.3) to fetch the latest bug fixes and features as well as fixing CVE-2025-41234Junit5, as it is provided transitively byspring-boot-starter-test. Keeping it explicitly declared leads to version conflicts, which goes against the JUnit project's recommendations for Spring Boot.How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)
Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)
A picture of a cute animal (not mandatory but encouraged)