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)
