Gradle-1.7-rc-1: offline support broken

Old Forum Archive
1

Hello,

With 1.7-rc-1, I tried to use the --offline option to run my build and it fails with an error resolving the buildscript dependencies.

I downloaded 1.7-rc-1 and ran a build without realizing that I didn’t have my network and it failed to resolve the buildscript dependencies. After the failure, I re-ran the build with --offline flag but it still continues to fail to resolve the dependencies.

I switched back to a previous version of Gradle (1.4) and with the --offline option (and no network), the build works fine.

I expected the --offline option to be able to build even with no network available. Has this changed in any way for 1.7?

2

The Gradle binary cache format has changed slightly between 1.4 and 1.7. This means that Gradle won’t reuse your previously downloaded artifacts until they have been verified via SHA1 checksum against the originating server. In order to do so, Gradle needs to have network connectivity.

Once you’ve successfully resolved once with 1.7, using ‘–offline’ should work as expected.

3

Thanks!

4

We are using Gradle 1.10 and are observing the same problem originally reported in this thread.

I have a snapshot dependency in my buildscript block

buildscript {
  dependencies {
    classpath 'com.internal.company:my-plugin:1.0.0-SNAPSHOT'
  }
}

Reproduce steps 1) I set 

configurations.all.resolutionStrategy.cacheDynamicVersionsFor 0, ‘seconds’

This should force the dependency to be resolved every time I do a build. 2) Connect to the network and do a build to force the SNAPSHOT to download 3) Disconnect the network 4) Now do a clean build with the “–offline” option. It fails trying to resolve SNAPSHOT dependency.

Is there a way around this or is this a bug? Thanks.

5

Can you please try again with Gradle 1.11-rc-1? This could be related to http://issues.gradle.org//browse/GRADLE-3017 which should be fixed in 1.11.

6

Using Gradle 1.11-rc-1 did not fix the problem. I even tried completely removing the .gradle/caches directory and starting from scratch.

This is actually a significant problem for our workflow since certain internal plugins and libraries are only available when connected to the VPN. We cannot require our developers to always be connected to the VPN to build code when a perfectly good copy of the jar exists already in their local cache.

Not sure how related this is to issue you referenced. It seems like that issue is for refreshing ivy repositories. This is for working with already cached, offline resources.

Also, that issue is not reported as being fixed in 1.11; it is still Unresolved.

One final note: It actually looks like this problem exists for non-SNAPSHOT/dynamic artifacts also. Is there something different about how the buildscript classpath dependencies are resolved. Does “–offline” get ignored in that case? Seems that way.

7

Sorry, I missed the fact that that your issue concerns non-SNAPSHOT, buildscript dependencies. Can you raise a separate forum issue? This isn’t the same problem as that originally reported.

8

I’ve done a little more investigation, and I think “offline” mode is working ok. But I have a question.

We have an internal Sonatype Nexus repostirory for our artifacts that is only available when connected to the VPN. We had noticed some long timeout issues before, so we wrapped the repository definition in our build script like so:

repositories {
    if (System.getenv("DISABLE_VPN_NEXUS") == null) {
      maven {
        url "${internal_nexus_url}/content/groups/public"
      }
    }
    mavenCentral()
    mavenLocal()
  }

When the environment variable was set to skip this repo definition, we were getting the cannot find artifact problem, even though it was in our cache. Am I correct in deducing that repository information is included in the cache checksums for artifacts?

9

That’s correct. For reproducibility reasons, a build won’t get cached artifacts downloaded from a repo that’s not declared in the build.

10

Gradle will however compare the checksum of a downloaded artifact from one repo with the reported checksum from another repo, to avoid downloading it again. But this won’t work in offline mode, since we are not able to determine even the checksum reported by the remote server.