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