IMO, dependency constraints that are available in Gradle 4 are not a substitute for the dependency management plugin. However, it may be that the improved pom support that's coming in Gradle 5.0 could be. It depends on your specific needs. There's as an open issue <https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/211> that discusses some of the differences. Once Gradle 5 has GAed, I expect the issue will result in some documentation based on the information in it.
Andy On Fri, Nov 16, 2018 at 6:26 PM John Blum <jb...@pivotal.io> wrote: > Good question, and that may be a better question for Andy Wilkinson to > answer since Andy created the Gradle dependencyManagement plugin. We/I use > it quite extensively and with good results. > > On Fri, Nov 16, 2018 at 9:38 AM Robert Houghton <rhough...@pivotal.io> > wrote: > >> Thanks John. >> >> Do you foresee the native Gradle DSL >> >> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html >> as an *eventual* replacement for the dependency-management-plugin you >> reference? >> >> On Tue, Nov 13, 2018 at 9:09 AM John Blum <jb...@pivotal.io> wrote: >> >> > If you'd like Maven dependencyManagement like behavior in Gradle, then >> you >> > should have a look at... >> > >> > https://github.com/spring-gradle-plugins/dependency-management-plugin >> > >> > -j >> > >> > On Tue, Nov 13, 2018 at 8:10 AM, Bill Burcham <bburc...@pivotal.io> >> wrote: >> > >> > > @Patrick Rhomberg <prhomb...@pivotal.io> I've never seen the >> > > dependencyManagement element survive in a published POM before. >> > > >> > > Since it sounds like you're asserting that you saw that element in a >> > > published POM (published by Gradle), I decided to verify that. I ran >> this >> > > from the Geode develop branch just now: >> > > >> > > ./gradlew build publishMavenPublicationToMavenLocal -x javadoc >> > > -Dskip.tests=true >> > > >> > > When I look >> > > at ~/.m2/repository/org/apache/geode/geode-core/1.9.0- >> > > SNAPSHOT/geode-core-1.9.0-SNAPSHOT.pom >> > > I see no dependencyManagement section. >> > > >> > > The absence of that element comports with my experience. My >> experience w/ >> > > the dependencyManagement element is that it is used when you're using >> > Maven >> > > to manage your build. It is wonderful for DRYing up what would >> otherwise >> > be >> > > unmanageable version information spread among lots of pom.xml (source) >> > > file. >> > > >> > > "dependency constraints" in Gradle sounds like it'd be a big step >> forward >> > > for similar reasons. I'd assume that "dependency constraints" don't >> > result >> > > in a dependencyManagement element in any published POM file though. >> > > >> > > >> > > On Wed, Nov 7, 2018 at 10:00 AM Jacob Barrett <jbarr...@pivotal.io> >> > wrote: >> > > >> > > > The dependency management element applies dependency constraints to >> > first >> > > > class dependencies and transitive dependencies. For example in >> > dependency >> > > > management of this say A:1 and B:2 it does not mean your module will >> > > > necessarily depend on A:1 and B:2 but if the module or transitive >> > module >> > > > does that the versions will be nudged to match these constraints. So >> > then >> > > > if you module you have a dependency section that includes A it will >> > > become >> > > > A:1 and if A:1 depends on B:1 then B:1 will be nudged to B:2. >> > > > >> > > > -Jake >> > > > >> > > > >> > > > > On Nov 6, 2018, at 3:25 PM, Anthony Baker <aba...@pivotal.io> >> wrote: >> > > > > >> > > > > I want reproducible builds. If dependency locking [1] works I >> would >> > be >> > > > open to dynamic versions [2]. >> > > > > >> > > > > Anthony >> > > > > >> > > > > [1] >> > https://docs.gradle.org/current/userguide/dependency_locking.html >> > > > > [2] >> > > > https://docs.gradle.org/current/userguide/declaring_ >> > > dependencies.html#sub:declaring_dependency_with_dynamic_version >> > > > > >> > > > > >> > > > > >> > > > >> On Nov 6, 2018, at 3:02 PM, Patrick Rhomberg < >> prhomb...@apache.org> >> > > > wrote: >> > > > >> >> > > > >> My current question surrounds the structure of POMs in specifying >> > > > version >> > > > >> information. Gradle supports `dependency constraints` to unify >> > > library >> > > > >> versioning. This seems to me to be a clean, concise alternative >> to >> > > our >> > > > >> current approach of cluttering the project property space with >> > > > >> project.'library.version', with mixed adherence throughout our >> build >> > > > files. >> > > > > >> > > > >> > > >> > >> > >> > >> > -- >> > -John >> > john.blum10101 (skype) >> > >> > > > -- > -John > john.blum10101 (skype) >
