(Not) Picking transitive dependencies from mavenLocal()


(Gordan Krešić) #1

There are already a lot of topics regarding mavenLocal(), but I think I’ve stumbled upon something different.

I have a lib build by Maven and main project that uses Gradle. Since I’m debugging lib, I’m using HEAD-SNAPSHOT version from oss.sonatype.org:

repositories {
	maven {
		url "https://oss.sonatype.org/content/repositories/snapshots"
	}
	mavenCentral()
}

dependencies {
	compile	'com.github.tdesjardins:gwt-ol3:HEAD-SNAPSHOT'
}

If I now list dependencies, I get gwt-ol3 and all of it’s transitive dependencies, as expected.

However, if I download, build and install that lib locally and add mavenLocal() to repositories:

repositories {
	mavenLocal()
	mavenCentral()
}

dependencies {
	compile	'com.github.tdesjardins:gwt-ol3:HEAD-SNAPSHOT'
}

Now I’m getting only gwt-ol3, but none of it dependencies. And here is the fun part - if I substitute mavenLocal() with a url pointing to my local folder where it is located:

repositories {
	maven {
		url '/home/gkresic/.m2/repository'
	}
	mavenCentral()
}

dependencies {
	compile	'com.github.tdesjardins:gwt-ol3:HEAD-SNAPSHOT'
}

then I get all the dependencies right again.

Things I’ve verified:

  • POM in local repo is exactly the same as the one on oss.sonatype.org
  • if I create blank Maven project with same configuration, I get dependencies right

Gradle is at latest version, 4.0.1.


(uklance) #2

My guess is that you previously didn’t have the pom files in your maven local directory when you resolved the dependency. Gradle cached the result and is now using its cache. By changing to maven { url ... } } you have changed the cache key that gradle uses internally, forcing it to start from scratch.

I’m guessing if you delete the gradle build cache directory it’ll magically start working with mavenLocal()


(Gordan Krešić) #3

Did that already, not 100% sure at which time, but definitely did that. Didn’t help.

I’m reluctant to do so again because I takes time to re-populate cache in my case, but I can confirm that using --refresh-dependencies does not work.


(Predrag Knezevic) #4

I am seeing the very same behavior…