Gradle

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
To raise new issues or bugs against Gradle, please use forums.gradle.org.
  • Gradle
  • GRADLE-320

Gradle should work in offline mode to load classes from the local cache

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Resolution: Fixed
  • Affects Version/s: 0.4
  • Fix Version/s: 1.0-milestone-8

Description

It would be cool if gradle works in offline mode. for example: currently if a project use snapshot dependencies and the internet connection is lost then gradle stops the build because ivy cant reload deps from the online repo. but it would be nice if gradle use the previous downloaded snapshot jars from the local cache.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • History
  • Activity
  • TeamCity
  • Commits
  • Source
  • Reviews
Hide
Permalink
Adam Murdoch added a comment - 02/Jan/10 5:40 PM

This should also work for downloaded scripts

Show
Adam Murdoch added a comment - 02/Jan/10 5:40 PM This should also work for downloaded scripts
Hide
Permalink
Thomas Glaeser added a comment - 11/Dec/10 5:49 AM - edited

This should also be available as a command line switch. Looks like this can be easily implemented using the Ivy ttl property.

----- Szczepan's disclaimer
"-Divy.cache.ttl.default" is not a workaround for offline builds, e.g. using this setting will not make gradle work in offline way.

It may be used as workaround for slow builds when version ranges are used. At this moment, ivy version ranges with gradle make dependency resolving slow because you'll have extra remote calls with each build regardless of your local cache.
----- End of disclaimer and sorry for hijacking your comment

Offline mode:

gradle clean build -Divy.cache.ttl.default=eternal

Online mode:

gradle clean build -Divy.cache.ttl.default=1ms

Instead of having a binary switch, it would be nicer to allow specifying the ttl without using the -D switch. Something like

gradle clean build --ttl 1m 23ms

Can we get this for 0.9?

BTW, this does not work for changing dependencies from the buildscript section. Why?

Show
Thomas Glaeser added a comment - 11/Dec/10 5:49 AM - edited This should also be available as a command line switch. Looks like this can be easily implemented using the Ivy ttl property. ----- Szczepan's disclaimer "-Divy.cache.ttl.default" is not a workaround for offline builds, e.g. using this setting will not make gradle work in offline way. It may be used as workaround for slow builds when version ranges are used. At this moment, ivy version ranges with gradle make dependency resolving slow because you'll have extra remote calls with each build regardless of your local cache. ----- End of disclaimer and sorry for hijacking your comment Offline mode:
gradle clean build -Divy.cache.ttl.default=eternal
Online mode:
gradle clean build -Divy.cache.ttl.default=1ms
Instead of having a binary switch, it would be nicer to allow specifying the ttl without using the -D switch. Something like
gradle clean build --ttl 1m 23ms
Can we get this for 0.9? BTW, this does not work for changing dependencies from the buildscript section. Why?
Hide
Permalink
Russ Egan added a comment - 06/Jan/11 8:41 PM

I ran into a similar use case, but I don't think it would be addressed by Ivy's TTL setting. Indeed, I don't see a way to have Ivy cope with this without a full-fledged offline mode. I could handle it if gradle let me specifically map which repositories it should search for a particular dependency.

Say I have two repositories:

repositories {
  repo1 ...
  repo2 ...
}

I have a dependency I need from repo2. repo2 is second in the list because all the rest of my dependencies come from repo1. I build when both are online, everything works, everything is cached by ivy.

I build when both repos are offline. It finds the dependency in the ivy cache, but the debug message says its rejecting it because the cached copy was originally resolved by the wrong repo. Ivy always wants to try and find the dependency in repo1 every time, even if it was previously found in repo2 and cached. Ivy remembers the cached copy came from repo2, and it wants to try and find it in repo1 first.

It attempts to contact repo1, eventually times out, then falls back on the cached copy from repo2. So the build does succeed, it just adds a couple minutes to the build time.

If in the dependency, I could specify which repos to use, that would resolve the problem. Or if ivy just had a true offline mode...

Show
Russ Egan added a comment - 06/Jan/11 8:41 PM I ran into a similar use case, but I don't think it would be addressed by Ivy's TTL setting. Indeed, I don't see a way to have Ivy cope with this without a full-fledged offline mode. I could handle it if gradle let me specifically map which repositories it should search for a particular dependency. Say I have two repositories:
repositories {
  repo1 ...
  repo2 ...
}
I have a dependency I need from repo2. repo2 is second in the list because all the rest of my dependencies come from repo1. I build when both are online, everything works, everything is cached by ivy. I build when both repos are offline. It finds the dependency in the ivy cache, but the debug message says its rejecting it because the cached copy was originally resolved by the wrong repo. Ivy always wants to try and find the dependency in repo1 every time, even if it was previously found in repo2 and cached. Ivy remembers the cached copy came from repo2, and it wants to try and find it in repo1 first. It attempts to contact repo1, eventually times out, then falls back on the cached copy from repo2. So the build does succeed, it just adds a couple minutes to the build time. If in the dependency, I could specify which repos to use, that would resolve the problem. Or if ivy just had a true offline mode...
Hide
Permalink
Oleksandr Maksymchuk added a comment - 22/Jan/11 12:30 PM - edited

In our case we have few third-party libraries which we keep locally and reference them as:

repositories {
    mavenCentral()
    flatDir name: 'localRepository', dirs: "$webInfDir/lib"
}

but each time we run gradle it tries to fetch those libs from central.
Is there any cure for that?

But it is more if it tries to download from central libs but some html is returned instead and so puts corrupted jars into gradle cache requiring manual deletion of those to recover.

:compileJava
error: error reading somejar-3.2.1.jar; error in opening zip file
FAILURE: Build failed with an exception.

Show
Oleksandr Maksymchuk added a comment - 22/Jan/11 12:30 PM - edited In our case we have few third-party libraries which we keep locally and reference them as:
repositories {
    mavenCentral()
    flatDir name: 'localRepository', dirs: "$webInfDir/lib"
}
but each time we run gradle it tries to fetch those libs from central. Is there any cure for that? But it is more if it tries to download from central libs but some html is returned instead and so puts corrupted jars into gradle cache requiring manual deletion of those to recover. :compileJava error: error reading somejar-3.2.1.jar; error in opening zip file FAILURE: Build failed with an exception.
Hide
Permalink
Hans Dockter added a comment - 24/Jan/11 4:19 AM

You could try to change the order and declare flatDir first.

Another approach would be to use non repository dependencies.

dependencies {
   compile fileTree(dir: "$webInfDir/lib", includes: ['*.jar'])
}

This is not as declarative, as it adds all dependencies of the lib directory.

You could also do something like:

dependencies {
   compile files("$webInfDir/lib/junit-4.4.jar", "$webInfDir/lib/jmock-2.0.jar")
}

We are working on making such scenarios more convenient do deal with.

Show
Hans Dockter added a comment - 24/Jan/11 4:19 AM You could try to change the order and declare flatDir first. Another approach would be to use non repository dependencies.
dependencies {
   compile fileTree(dir: "$webInfDir/lib", includes: ['*.jar'])
}
This is not as declarative, as it adds all dependencies of the lib directory. You could also do something like:
dependencies {
   compile files("$webInfDir/lib/junit-4.4.jar", "$webInfDir/lib/jmock-2.0.jar")
}
We are working on making such scenarios more convenient do deal with.
Hide
Permalink
Oleksandr Maksymchuk added a comment - 25/Jan/11 7:52 AM

Hans, thanks for detailed answers about possible workarounds, I didn't know about them so those are very helpful. Looking forward to other enhancements you are doing.

Show
Oleksandr Maksymchuk added a comment - 25/Jan/11 7:52 AM Hans, thanks for detailed answers about possible workarounds, I didn't know about them so those are very helpful. Looking forward to other enhancements you are doing.
Hide
Permalink
Russel Winder added a comment - 28/Sep/11 2:03 AM

If this issue or any connected ones hinder with Gradle being used offline, then it should be considered a blocker, or at least critical, for the 1.0 release. If Gradle 1.0 required permanent connectedness to the Internet to work once at 1.0 then it would have to be considered to have missed the boat.

Show
Russel Winder added a comment - 28/Sep/11 2:03 AM If this issue or any connected ones hinder with Gradle being used offline, then it should be considered a blocker, or at least critical, for the 1.0 release. If Gradle 1.0 required permanent connectedness to the Internet to work once at 1.0 then it would have to be considered to have missed the boat.

People

  • Assignee:
    Unassigned
    Reporter:
    Marko Bauhardt
Vote (25)
Watch (20)

Dates

  • Created:
    08/Dec/08 1:26 AM
    Updated:
    04/Jan/13 5:09 AM
    Resolved:
    04/Mar/12 5:15 PM
  • Atlassian JIRA (v5.0.3#729-sha1:bf569e4)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Gradle. Try JIRA - bug tracking software for your team.