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) >
