Gradle does not add transitive dependencies to war's WEB-INF/lib folder


(Alek Vachev) #1

I have a web project that produces a war. The war adds a jar (another project of mine posted on an external repo) as compile dependency. This jar has its own compile dependency, which is listed in the jar’s pom file, as well as in the project’s build script (this is a Gradle project). I would like to add the jar, as well as all of its own dependencies to my war’s WEB-INF/lib folder. However, when I build the web project with Gradle, only the direct dependency is added, not the transitive ones.

Here is my web project’s build script:

apply plugin: 'war'
  repositories {
         maven {url "http://repo-url"}
}
  configurations.all {
    resolutionStrategy {
        cacheChangingModulesFor 0, 'seconds'
    }
}
  dependencies {
      compile('com.company.group:artifact-name:1.0.0-SNAPSHOT') {
        changing = true
        transitive = true
    }
}

The com.company.group:artifact-name:1.0.0-SNAPSHOT does have its own POM, which lists the following dependency:

<dependency>
<groupId>us.codecraft</groupId>
<artifactId>xsoup</artifactId>
<version>0.2.0</version>
<scope>compile</scope>
</dependency>

Also, I’ve set cacheChangingModulesFor to 0 seconds, so that, effectively, the latest version of the SNAPSHOT jar is used every time.

The issue I am having is the ‘us.codecraft:xsoup:0.2.0’ artifact does not get included in the war, even though it is a transitive dependency of the war.

Any thoughts? Ask for more details, if anything is unclear.


(Peter Niederwieser) #2

See my comment on Stack Overflow.


(Alek Vachev) #3

Hi Peter,

I do not see the dependency in question under the compile dependencies list. Could it be that I actually have to use it (import from it) in my code in order for the module to download the dependency?


(Peter Niederwieser) #4

It doesn’t matter if the dependency is actually used by your code. If ‘gradle dependencies’ doesn’t show the dependency, then something fundamental is wrong, but it’s hard to say from here what it is. Perhaps the dependency hasn’t been published correctly to the repository. First thing I’d do is to check the ‘–info’ and ‘–debug’ logs.


(Alek Vachev) #5

Hmm, so I tried this whole exercise again with a different transitive dependency. When I built the web project, the new transitive dependency was listed under the compile dependencies, but yet again it was not found in the war. Next I built again with --info. No useful information was provided. However, when I ran the dependencies task again, the transitive dependency was missing from the list.

I guess I will call this Gradle feature vanishing dependencies.


(Peter Niederwieser) #6

Very strange. I’d be surprised is this was a problem on Gradle’s side. Perhaps experiment with the web samples in the full Gradle distribution and compare your build to them.


(Alek Vachev) #7

Ok, I found the issue. It doesn’t have anything to do with Gradle’s handling of transitive dependencies. The problem was that Gradle had a hard time deciding which version of my snapshot artifact was the most up-to-date one.

Remember I said above that I built once and the dependency was listed, then built again and the dependency had vanished. That second time, along with subsequent builds, Gradle would assume that a snapshot jar from March 10th was the latest and most up-to-date one, and of course this jar did not have the transitive dependency I was targeting. Once I deleted the old snapshot, problem was resolved.

Thanks, Peter. Your suggestion to use --info and --debug logs actually led me to the resolution of this problem.


(Peter Niederwieser) #8

Make sure to always publish unique snapshots, i.e. snapshots with a timestamp in the file name. (Gradle will do this automatically.) Also the published ‘maven-metadata.xml’ should point to the latest snapshot.