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)
