Slackbot
03/30/2022, 1:24 PMChris
03/30/2022, 3:17 PMThis is great and all... but none of this works if a Gradle user has turned on. The ultimate problem here seems to be that Jackson wants to use micro-versions for security fixes to individual packages, but the current system of BOMs and intermodule dependency declarations that connect the Jackson modules doesn’t account for this.failOnVersionConflict()
I believe there are two outstanding issues here:
1. The Gradle module metadata published with each modules links the modules back to the originally released 3-digit BOM version only. I think that should probably be a range:to correctly capture that “aligned” could mean using a module that has no security fixes with a BOM that captures security fixes.[2.13.2,2.13.3)
2. The intermodule dependencies are “fixed” and not version ranges. If security fixes are done using the fourth digit, then dependencies on central modules likeorjackson-core
should capture that using appropriate ranges. Of course currently this is indirectly tied back to the parent POM which does the central dependency management for the whole system, which is also the BOM for the system - I fear that fact might make things yet more complicated.jackson-databind
You can see some that “fear” coming out in the dependency graph of the security fixedwhere the POM ‘parent’ chain looks like this:jackson-databind:2.13.2.1
- that’s all great. However the dependency management injackson-databind:2.13.2.1 -> jackson-base:2.13.2.20220324 -> jackson-bom:2.13.2.20220324
then pins other modules to 2.13.2 which ends up pulling the 2.13.2 BOM as well, which stands in conflict. I wonder if this is even fixable without decoupling the POM parent from the BOM?jackson-bom
Louis Jacomet
03/30/2022, 4:58 PMJendrik Johannes
03/30/2022, 5:58 PM"requires": "[2.13.2,2.13.3)"
in published metadata is a very bad Idea IMO. It’s an open range which makes a build not reproducible. Ranges alone should never be used in published metadata.Chris
03/30/2022, 6:05 PMJendrik Johannes
03/30/2022, 6:06 PMJendrik Johannes
03/30/2022, 6:07 PMThats not an open range…Sorry wrong wording I used. Point is that it is a range. Once there is a new micro release of the BOM, resolution results automatically change in your build.
Chris
03/30/2022, 6:10 PM[2.13.2,2.13.3)
, so as to cover any future security fixes.
2. The BOM should capture a specific set of artifacts (no ranges allowed).
3. No Jackson module should ever pull in a BOM.
The existing version alignment mechanism that Jackson uses covers the scenario where the “compatibility rules” are “everything must be the same version”. That’s explicitly not true here, hence the existing scheme doesn’t work.Chris
03/30/2022, 6:13 PMfailOnVersionConflict()
is rare… but I would argue it is correct. Anyone not using this is inviting optimistic version conflict resolution to substitute a very specific looking 1.2.3
with the truly open range: [1.2.3,)
. Then they’re just relying on their own (and all downstream consumers) testing to make sure things don’t break.Jendrik Johannes
04/05/2022, 3:52 PMfailOnVersionConflict()
. I think there is no way to implement the alignment-through-bom pattern (https://blog.gradle.org/alignment-with-gradle-module-metadata) without always causing a version conflict If the component versions are not always the same (as it is the case for micro-patches in Jackson). Because then the same version of a component may be referenced in multiple BOM versions, but the component can only reference one BOM version (the one that was available when the component was published).
So if we want to keep the failOnVersionConflict()
case working, I think the only option is to remove the Gradle Metadata again from Jackson completely and not have the alignment pattern in there anymore.
@Louis Jacomet could you or someone else give a comment on where Gradle stands here officially? What’s the stance towards failOnVersionConflict()
?Chris
04/05/2022, 4:54 PM$ git --no-pager log -SfailOnVersionConflict
commit b0ff92221a9565e8079101da2973d27819f935bf
Author: Chris Dennis <chris.w.dennis@gmail.com>
Date: Thu Apr 29 14:01:32 2021 -0400
Convert from cross-project configuration to convention plugins
commit ed94e7e7ec9bb659b3cf0b6c08f5a25c48d6c867
Author: Louis Jacomet <louis.jacomet@terracottatech.com>
Date: Thu Aug 24 21:29:05 2017 +0200
Migrate to Gradle 4.3.1
Seriously improves overall build time
Especially when simply wanting to build a kit or run all tests.
🤣Louis Jacomet
04/06/2022, 10:24 AMfailOnVersionConflict
are at odds indeed.
As indicated by Jendrik, adding ranges to published version can be tricky as it might causes changes in resolution whenever a patch version appears.
So I am not sure there is a general answer for this problem.
One option that could be tried on the Jackson end would be to do the alignment with ranges, as suggested by Chris, but also specifying the base release as a prefer
. This would make sure that the base version is always selected unless a patch version enters the graph explicitly.
I have not tested this so it might still be a problem with failOnVersionConflict
in some corner cases.Jendrik Johannes
04/06/2022, 1:49 PMfailOnVersionConflict
.
Without the failOnVersionConflict
I think it’s quite neat that the approach even supports alignment with the additional micro versions. Not sure what to do now. 🤔