[GRADLE-320] Gradle should work in offline mode to load classes from the local cache Created: 08/Dec/08 Updated: 04/Jan/13 Resolved: 04/Mar/12 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 0.4 |
Fix Version/s: | 1.0-milestone-8 |
Type: | New Feature | ||
Reporter: | Marko Bauhardt | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 25 |
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. |
Comments |
Comment by Adam Murdoch [ 02/Jan/10 ] |
This should also work for downloaded scripts |
Comment by Thomas Glaeser [ 11/Dec/10 ] |
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 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. 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? |
Comment by Russ Egan [ 06/Jan/11 ] |
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... |
Comment by Oleksandr Maksymchuk [ 22/Jan/11 ] |
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. 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 |
Comment by Hans Dockter [ 24/Jan/11 ] |
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. |
Comment by Oleksandr Maksymchuk [ 25/Jan/11 ] |
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. |
Comment by Russel Winder [ 28/Sep/11 ] |
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. |