Buildship 2.0 doing strange --refresh-dependencies


(Blue Ananas) #1

I have a snapshot artifact dependency in my project. The snapshot was the updated from -18 to -19

Doing Gradle / Refresh Gradle Project from the projects context menu does not fetch the newer artifact from the repo.
Even worse: if I delete the the artifact from the local repo, the older -18 artifact is downloaded again.
It’s always the older artifact which gets linked into the eclipse buildpath.

gradlew build --refresh-dependenciesworks as expected: the last -19 artifact is pulled from the external repo if needed and compile is using it.

My current fix is to copy the newer -19 onto the older -18 artifact in the file tree of the local repo.

Maybe Buildship isn’t doing a --refresh-dependencies at all and using some cached pom files?

(Stefan Oehme) #2

Buildship does not run --refresh-dependencies, as that would be very expensive to do on every little change. If you’ve run some build with --refresh-dependencies or the timeout expired, it should use the newer artifact though. Buildship doesn’t do anything special here, it invokes the Gradle daemon just like the command line would do.

So to clarify: Buildship still uses the -18 artifact after a refresh even though the command line uses -19?

(Blue Ananas) #3

It’s even worse, if the -18 artifact is deleted from the local repo, Gradle / Refresh Gradle Project will download and link the -18 artifact again even though the newer -19 artifact exists in the remote and the local repo.

It seems that Buildship is caching the snapshot pointer into the remote repo and stays with it as long as the artifact is still found there. Refresh Gradle Project definitely needs some optional --refresh-dependencies or something like clear my cache as well.

(Stefan Oehme) #4

There is no cache in Buildship, it gets the dependencies from Gradle directly. Are you using the same Gradle version on the command line and in Buildship (i.e. using the wrapper)? Can you share a reproducible example?