Gradle 2.5 and above ignoring excluded dependencies in genereated ivy.xml

Old Forum Archive Bugs
,
1

We are in process of upgrading Gradle 2.4 to 2.5 and came across this issue.

Our projects got few dependencies with excluding some transitives like below

compile (“org.drools:drools-core:6.3.0.Final”){
exclude group : ‘org.mvel’
}
compile (“org.springframework:spring-core:4.2.5.RELEASE”){
exclude group : ‘commons-logging’
}

When we run uploadArchives, it is generating ivy.xml with entries as

    <dependency org="org.drools" name="drools-core" rev="6.3.0.Final" conf="compile-&gt;default"/>
     <dependency org="org.springframework" name="spring-core" rev="4.2.5.RELEASE" conf="compile-&gt;default"/>

But when we ran the same with Gradle 2.4, it  shows as

  <dependency org="org.drools" name="drools-core" rev="6.3.0.Final" conf="compile-&gt;default">
       <exclude org="org.mvel" module="*" name="*" type="*" ext="*" conf="compile" matcher="exact"/>
     </dependency>
     <dependency org="org.springframework" name="spring-core" rev="4.2.5.RELEASE" conf="compile-&gt;default">
       <exclude org="commons-logging" module="*" name="*" type="*" ext="*" conf="compile" matcher="exact"/>
     </dependency>

I tried running even with gradle 2.11 and I still the same behavior. Is this intentional?

Attaching sample project to reproduce the issue Gradle-ivy-Test.zip (59.9 KB)

Just try running

“Gradle uploadArchives” with Gradle 2.4 and 2.5, and should see the difference…

2

I did some debugging on your example and found the place in the gradle code, where the exclude rules get lost:

The class org.gradle.internal.component.external.model.DefaultIvyModulePublishMetaData has a method addDependency which converts a org.gradle.internal.component.model.DependencyMetaData to a org.apache.ivy.core.module.descriptor.DefaultDependencyDescriptor. Both data structures have attributes which model the exclude rules. However the method does not transfer them, so they get lost. Looking at the git history of the file it does not seem to be an intended change in the behaviour. So I guess it is a bug.

3

Thanks for reporting. This looks like a bug. I was able to reproduce the issue and opened the following issue: GRADLE-3440

4

Thanks @bmuschko for creating GRADLE-3440