This is the intended behaviour. Each dependency edge is treated independently, and a module is included if there is a path to the module that does not exclude it.

I understand that this is the intended behaviour, but I'm surprised that you apparently don't think that it could be improved. One of Gradle's benefits is the reduced verbosity of our build scripts but to work around this behaviour we'd have to repeat the exclude for every dependency with a transitive dependency on spring-core. For example:

compile("org.springframework:spring-tx:4.0.3.RELEASE") {
        exclude group: "commons-logging", module: "commons-logging"
compile("org.springframework:spring-core:4.0.3.RELEASE") {
        exclude group: "commons-logging", module: "commons-logging"
}

The unwanted side-effect of this is that the generated POM files now contain superfluous exclusions. An alternative that Peter suggested was to use configuration-wide or even project-wide exclusions. While it addresses the verbosity of the build script by removing the repetition of the exclude, it makes the problem of the superfluous exclusions even worse. We could, as Peter has suggested, post-process the generated POMs somehow, but then we're back repeating ourselves as the knowledge of the need to exclude commons logging would be duplicated and spread across multiple places in our build.

I'd love to see an improvement to Gradle so that exclusions can be declared in a DRY manner and without having to resort to post-processing to also have concise generated pom files.

Andy Wilkinson, we're unlikely to change this behaviour, but we can certainly do things so you end up with a concise build and a reasonable looking pom.

Why is it that you want to exclude commons-logging?

Typically we exclude commons-logging as a project has elected to use SLF4J instead. In that scenario we exclude commons-logging and depend on jcl-over-slf4j

Ok. The idea is that you would use a dependency resolve rule instead to substitute all usages of commons-logging with jcl-over-slf4j. Does this not work for you?

It somewhat works for the commons-logging case. We'd need to keep the exclude on the spring-core dependency declaration as we need the exclusion to be included in the generated pom. I say somewhat, as I'm not keen on having to duplicate the don't-use-commons-logging logic.

We also have numerous cases where we just want to exclude a dependency entirely, for example a JAXB 2.0 dependency that is redundant as it's included in JDK 6 and later. Do you have a suggestion for this scenario? It doesn't look like a dependency resolve rule can be used to exclude a dependency.