https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
c
one option for distributing constraints/rules on dependencies (direct & transitive) is to use custom Nebula resolution rules for alignment, replacement, substitution, exclusion. Useful for say forcing secure versions. Behind the scenes this is using the various Gradle APIs to create replacement rules, alignment rules, constraints, etc - which can, of course, be accomplished in other ways (e.g. your own custom plugin distribution that calls the same APIs). Version catalogs were not intended/designed to, by themselves, affect dependency resolution.
A catalog helps with centralizing the dependency versions and is only, as it name implies, a catalog of dependencies you can pick from. We recommend using it to declare the coordinates of your dependencies, in all cases. It will be used by Gradle to generate type-safe accessors, present short-hand notations for external dependencies and it allows sharing those coordinates between different projects easily. Using a catalog will not have any kind of consequence on downstream consumers: it’s transparent to them.
m
just saying that with 1) you can import a catalog and override the versions declared in it at the same time. The Micronaut catalogs declare versions for each library, so that you can do that.
so the first argument: "so cannot use the native version overriding feature in Version Catalog anymore" is technically wrong:
Copy code
versionCatalogs {
     create("foo") {
        from("...")
        version('groovy', '3.0.5') // override the version in the catalog
     }
}
"no native support for publishing a catalog and a platform from the same source" is not quite true either: the 
java-platform
plugin allows that. What is not very well supported is having properties for versions in the generated POM file.
Eventually, as Chris said, catalogs are not designed to "override" dependency resolution. That's why you need both a catalog (to "list" dependencies) and a platform/BOM (to carry constraints)
p
Thanks very much for the responses. I will look into the Nebula resolution rules. Melix, regarding the 
"so cannot use the native version overriding feature in Version Catalog anymore"
- the Solution (1) also calls for applying the micronaut platform/bom. So using the catalog version overriding. e.g. 
version('groovy', '3.0.5')
, may or may not work because the version is also hardcoded in the platform. It will work in some situations and won't in some . While that's predictable, it's not something I'd want non-expert Gradle users to deal with if there's a way. If there's no platform involved, the overriding will be a breeze for direct dependencies. Let me know if I'm missing something.
Melix, Regarding 
catalogs are _not_ designed to "override" dependency resolution
, I agree with that too. The proposed solution (3) will not change the design mechanics of the catalogs. We will only be adding extra convenience methods on the Gradle side to promote better utilization of catalogs for different scenarios. For example,
Copy code
constraints{ api myCatalog.bundles.someBundle } // I think this already works today. So technically an auto-generated bundle which includes all library entries will pretty much work like a platform without needing one. That is a big deal, to me, because there won't be a split brain anymore on versions between the catalog and the platform. 

constraints{ api myCatalog.bundles.someBundle {strictly true}} // adding such convenience might go a long way ..
Just my 2c based on playing with catalogs in the past few months to roll them out across the board at my place.
c
while large parts of (3) are doable today with Gradle API, that isn’t the intended use of catalogs. it mixes declaring a dependency version with declaring a constraint (maintenance headache for your catalogs - what is this definition used for?) - and for limited value, given the range of dependency management adjustment that is typically required. For example, that would offer no way of performing alignment, replacement, substitution or exclusion of dependencies, nor is there an avenue to handle capability/variant resolution.
thank you 1
6 Views
Open in Slack
PreviousNext
Powered by