Update fasterxml#3227
Conversation
e675eb8 to
9ea5d17
Compare
9ea5d17 to
23fd002
Compare
23fd002 to
c445258
Compare
c445258 to
1cedc0b
Compare
1cedc0b to
2bacc0d
Compare
aa2e368 to
53fd817
Compare
|
@malliaridis Do you want to handle this and related / dependent deps? I have scheduled it for rebase on next solrbot run to clean up the conflict. |
53fd817 to
8c13091
Compare
|
|
I will try to review this ideally by the end of this week. |
malliaridis
left a comment
There was a problem hiding this comment.
Looks good to me now. I believe the crave.io issues are not related to the dependency updates, but I will run it once more and merge it afterwards.
|
Btw. minimum supported Guava version is set to 22.0, but I believe it does not have any impact here or in |
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
|
@janhoy I have looked into the current test failures, and it seems that one test is related to CBOR serialization, part of the fasterxml databind module. It fails because the current bytes of the serialized object do not match the expected value (actual is lower). I am not sure if this is a (breaking or not) change caused by the update. Updating the expected bytes to the actual bytes fixes the test. Some other tests fail as well, but it seems it is not related to the update. I will try to troubleshoot a bit more, but I believe this would be the final state. |
| dependencies { | ||
| api platform(project(":platform")) | ||
| swaggerDeps platform(project(":platform")) | ||
| api platform(libs.fasterxml.jackson.bom) |
There was a problem hiding this comment.
I'm surprised to see jackson here, as I expect that our platform's role is to be all encompassing (to include jackson).
There was a problem hiding this comment.
If I remember correct, the issue comes from the way BOMs have to be added to resolve dependency versions. Our platform module goes through our libs.versions.toml file and adds all dependencies via api [dependency]. Later, the module is added as [configuration] platform(project(":platform")) to resolve dependencies.
However, in order for BOMs to take effect in dependency resolution, they have to be added via platform([bom-dependency]). Since we cannot reliably distinguish BOMs from other dependencies in our current setup, we have to manually add them.
We might be able to enlist the BOM dependencies in a seperate toml file and iterate over it in our platform module, so that we can run a different logic in platform/build.gradle, something like:
// platform/build.gradle
plugins {
id("java-platform")
}
dependencies {
constraints {
// Current logic
def versionCatalog = rootProject.extensions
.getByType(VersionCatalogsExtension).named("libs")
versionCatalog.libraryAliases.forEach { alias ->
def library = versionCatalog.findLibrary(alias)
api library.get()
}
// Additional new logic
def bomCatalog = rootProject.extensions
.getByType(VersionCatalogsExtension).named("bom") // <-- reference different toml file
bomCatalog.libraryAliases.forEach { alias ->
def library = bomCatalog.findLibrary(alias)
api platform(library.get()) // <-- this line makes the difference
}
}
}And then add only BOM dependencies to gradle/bom.versions.toml:
[versions]
amazon-awssdk = "2.32.31"
fasterxml = "2.20.0"
google-cloud-bom = "0.224.0"
grpc = "1.65.1"
netty = "4.2.6.Final"
opentelemetry = "1.56.0"
[libraries]
amazon-awssdk-bom = { module = "software.amazon.awssdk:bom", version.ref = "amazon-awssdk" }
fasterxml-jackson-bom = { module = "com.fasterxml.jackson:jackson-bom", version.ref = "fasterxml" }
google-cloud-bom = { module = "com.google.cloud:google-cloud-bom", version.ref = "google-cloud-bom" }
grpc-bom = { module = "io.grpc:grpc-bom", version.ref = "grpc" }
netty-bom = { module = "io.netty:netty-bom", version.ref = "netty" }
opentelemetry-bom = { module = "io.opentelemetry:opentelemetry-bom", version.ref = "opentelemetry" }I did not have enough time back then to experiment with that, but it may allow us to remove redundant dependencies to BOMs in our modules, like the one you pointed at.
There was a problem hiding this comment.
Thanks for that thorough response Christos.
Background: I've been looking at Solr's techniques to apply some techniques elsewhere.
There was a problem hiding this comment.
SOLR-18003 also shows a case where the BOM version resolution fails and we have to intervene.
This PR contains the following updates:
2.18.2->2.20.02.18.2->2.20.02.18.2->2.20.02.18.2->2.20.02.18.2->2.202.18.2->2.20.0Configuration
📅 Schedule: Branch creation - Every minute ( * * * * * ) (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Renovate Bot