@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. > > >
