Using a nightly build of gradle 1.7 (gradle-1.7-20130613220038+0000), I’ve come across a bug which seems related to GRADLE-1945.
I’ve been working to convert a maven build to gradle and was trying to track down why some of the jars in my war build via maven were not in the war artifact when build by gradle. I whittled down the problem to a reproducible case which involved gradle not handling properly an artifact’s pom file pulled down from a maven repository that has a element in it.
In my case, the artifact in question is “xml-apis:xml-apis:2.0.2”
In the maven central repo that pom has a relocation element that looks like this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>2.0.2</version>
<distributionManagement>
<relocation>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.0.b2</version>
</relocation>
</distributionManagement>
</project>
My gradle build looks like this:
apply plugin: "war"
repositories {
mavenCentral()
}
dependencies {
compile "xml-apis:xml-apis:2.0.2" // pom redirects to "xml-apis:xml-apis:1.0.2b"
compile "jdom:jdom:1.1"
// pom redirects to new groupId 'org.jdom'
}
task doIt << {
for(file in configurations.compile) {
println file.name
}
}
When I run the ‘doIt’ task above, I get the following output:
[lighthouse:~/tmp/duh] dlethin% gradle doIt
:doIt
jdom-1.1.jar
BUILD SUCCESSFUL
Note that the xml-api jar is not present. When I build a sample war using maven with the above dependency, xml-api-1.0.2b.jar does get packed in the war.
So gradle builds the war fine without fail, however the relocated jar is not packed into the war.
It should be noted that artifact relocation seems to partially work. GRADLE-1945 references jdom-1.1 which also has a relocation element (relocates the group ‘jdom’ to ‘org.jdom’. This seems to be processed fine by gradle as seen above, so it seem that particular use cases has been fixed.
However, with regards to xml-api’s relocation, it appears Gradle is not behaving as I would expect.
Perhaps another bug should be opened on this?
In the meantime, I’ll hunt through my transient dependencies and see where this is being picked up and I’ll see if I can get a workaround in place possibly to use the new dependency resolution rules.
Thanks.