[GRADLE-244] dependencyMechanism for a better control of dependencies in multiprojects Created: 26/Sep/08 Updated: 24/Jan/17 Resolved: 24/Jan/17
maven supports two types of dependencies. one is the normal "dependency" tag. And another way to define dependencies for multiprojects is to use the "dependencyManagement".
think the different between dependency and dependencyManagement is that a sub-module inherit the dependency definitions like "exclude" or "version" from the parent-project. But only if this dependency is configured in the sub-module.
+ see maven documentation http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
|Comment by Jon Cox [ 23/Jan/09 ]|
How might this look in terms of Gradle syntax?
Incidentally, I think Ivy's terminology "transitive override rules"
Someone has to explain to me what the difference is between "dependencyManagment" and "dependency" is,
Anyway, I added my rationale for preferring Ivy terminology to the discussion Hans started in
|Comment by Hans Dockter [ 26/Jan/09 ]|
For Gradle 0.6 we want to completely revisit and improve all of the dependency management related DSL stuff. So I hope we will have a lively discussion on the dev list soon on all this soon. I will also set up a Wiki page for this.
I doing some big refactoring right now to get better dependency API support for some of the stuff we want to do in 0.6.
|Comment by David Boden [ 06/Jan/13 ]|
I just wanted to add a comment to explain my experience of using the Maven <dependencyManagement/> block.
1. Controlling the version of direct transitive dependencies to maintain consistency across a multi-module build. This contributes towards a "version conflict resolution" mechanism, but has wider applicability. The versions are forced to be the specified version in <dependencyManagement/>.
The Gradle documentation talks about the available version conflict mechanisms:
44.2.3 Version conflicts
In this section it states:
In my view, something like the Maven <dependencyManagement/> section is required.
An example use case here is that when pulling in the 10 or so Spring dependencies, it makes sense for them all to be on the same version, regardless of what version has been pulled in from transitive dependencies. I use <dependencyManagement/> to force the version of spring-core, spring-context, spring-orm etc. to 3.2.0.RELEASE.
From what I can see, Gradle has slightly better support than Maven for excluding transitive dependencies. Something that Maven has been lacking for a long time is wildcard-based exclusions. You currently have to specify an exclusion for each artifact rather than saying "exclude javax.xml.*".
What Gradle doesn't appear to have is a standard mechanism for declaring exclusions that will apply a multi-module build. What you're essentially doing with the Maven exclusions is rewriting the transitive dependency's pom in the local repository as if it didn't declare the dependencies in the first place.
An example use case is that libraries built to run against older versions of Java typically include dependencies on libraries like Xerces, which are now built into the Java runtime. I tend to want to exclude those and use the built-in JRE XML parser.
|Comment by Benjamin Muschko [ 15/Nov/16 ]|
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 24/Jan/17 ]|
The work is now tracked via https://github.com/gradle/gradle/issues/1162.