https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
v
If you use them as 
platform(...)
they add according constraints. If you just use it as normal dependency, they should not have any effect iirc.
t
Well, except for resolving versions (and default scope?) of transitive dependencies! (Gradle also respects exclusions I think, right?)
r
Well, except for resolving versions (and default scope?) of transitive dependencies!
This is what I was wondering about. I didn't see anything in the user guide about it
Thinking it through, it's not clear that respecting 
<dependencyManagement>
versions would ultimately do anything, given that Gradle resolves to the latest version and not the version nearest the root
t
Anything that claims to being able to consume Maven artifacts must be prepared to resolve the chain of parent POMs and apply properties and dependencyManagement, and profiles (at least the activeByDefault ones). There might have been limitations in earlier versions of Gradle (I remember exclusions not working / being broken) but IIRC this is all OK now.
dependencyManagement declares version (and scope) that are "inherited" by dependency declarations. If a POM thus has a dependency without version, and nothing else in the project depends on that same dependency, Gradle must use the dependencyManagement to resolve a version for the dependency, otherwise it would be unable to resolve the dependency.
r
Got it. Thanks for clarifying
v
Ah, yeah, the 
platform(...)
is probably only necessary if it acutally is a BOM, so has 
<packaging>pom</packaging>
.
2 Views
Open in Slack
PreviousNext
Powered by