How might this look in terms of Gradle syntax?

Incidentally, I think Ivy's terminology "transitive override rules"
is much clearer & more obvious than Maven's term: "dependencyManagement".

Someone has to explain to me what the difference is between "dependencyManagment" and "dependency" is,
but when I hear the phrase "transitive override rules", I immediately know what's going on.

Incidentally, for those who haven't seen the difference in syntax, look at what Ivy does and compare that to how it looks in Maven

Anyway, I added my rationale for preferring Ivy terminology to the discussion Hans started in GRADLE-42
If anybody has other thoughts on this, I'd like to hear them. I only looked at Maven for a short while,
got turned off by it, then discovered Ivy in the context of Gradle & loved it. There's a chance I'm selling
Maven short here, but on the first go-around, it seems like maven vs ivy is like "huh?" versus "ahhhh!"

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.

I just wanted to add a comment to explain my experience of using the Maven <dependencyManagement/> block.
In my projects, it's used for two distinct purposes. These are grouped together in Maven, but I think they're conceptually quite separate.

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
http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:version_conflicts

In this section it states:

• We are working on making conflict resolution fully customizable.

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.

2. Declaring transitive dependency exclusions in a consistent way across a multi-module build.

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.

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:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

The work is now tracked via https://github.com/gradle/gradle/issues/1162.