How can I tell gradle to redownload dependencies from repositories?
Generally, you can refresh dependencies in your cache with the command line option --refresh-dependencies. You can also delete the cached files under ~/.gradle/caches. With the next build Gradle would attempt to download them again.
What is your specific use case? Do you use dynamic dependency versions or SNAPSHOT versions?
On Unix systems, you can delete all the existing artifacts (artifacts and metadata) Gradle has downloaded using:
rm -rf $HOME/.gradle/caches/
Note that --refresh-dependencies won't always re-download every artifact; it will use existing copies if they match what exists in the repository. From the Gradle User Guide, refreshing dependencies:
The --refresh-dependencies option tells Gradle to ignore all cached entries for resolved modules and artifacts. A fresh resolve will be performed against all configured repositories, with dynamic versions recalculated, modules refreshed, and artifacts downloaded. However, where possible Gradle will check if the previously downloaded artifacts are valid before downloading again. This is done by comparing published SHA1 values in the repository with the SHA1 values for existing downloaded artifacts.
[...]
It’s a common misconception to think that using --refresh-dependencies will force download of dependencies. This is not the case: Gradle will only perform what is strictly required to refresh the dynamic dependencies. This may involve downloading new listing or metadata files, or even artifacts, but if nothing changed, the impact is minimal.
If you are using a recent version of Gradle, you can use --refresh-dependencies option.
./gradlew build --refresh-dependencies
you can refer to the Gradle manual.
The --refresh-dependencies option tells Gradle to ignore all cached entries for resolved modules and artifacts. A fresh resolve will be performed against all configured repositories, with dynamic versions recalculated, modules refreshed, and artifacts downloaded.
You can tell Gradle to re-download some dependencies in the build script by flagging the dependency as 'changing'. Gradle will then check for updates every 24 hours, but this can be configured using the resolutionStrategy DSL. I find it useful to use this for for SNAPSHOT or NIGHTLY builds.
configurations.all {
// Check for updates every build
resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}
Expanded:
dependencies {
implementation group: "group", name: "projectA", version: "1.1-SNAPSHOT", changing: true
}
Condensed:
implementation('group:projectA:1.1-SNAPSHOT') { changing = true }
I found this solution at this forum thread.
For MAC
./gradlew build --refresh-dependencies
For Windows
gradlew build --refresh-dependencies
Can also try gradlew assembleDevelopmentDebug --refresh-dependencies
For Windows...in order to make gradle re-download specific dependencies:
delete the dependencies you want to re-download from the directory below:
C:\Users\%USERNAME%\.gradle\caches\modules-2\files-2.1
delete all metadata directories at the path:
C:\Users\%USERNAME%\.gradle\caches\modules-2\metadata-*
run gradle build (or gradlew build if using gradle wrapper) in the project's root directory.
note: the numbers in the file paths above might be different for you.
None of the solutions above worked for me.
If you use IntelliJ, what resolved it for me was simply refreshing all Gradle projects:
One can remove folder with cached jars.
In my case, on Mac the library was cached at path:
/Users/MY_NAME/.gradle/caches/modules-2/files-2.1/cached-library-to-remove
I removed the cached library folder ("cached-library-to-remove" in above example), deleted the build folder of my project and compiled again.
Fresh library was downloaded then.
To refresh cached 'release' version the only option is to clear local cache.
rm -rf $HOME/.gradle/caches/
To refresh cached 'snapshot' version you can:
./gradlew build --refresh-dependencies
For those who are wondering where to run gradle commands:
Open Android Studio
Click on Terminal(You will find it in the base of Android Studio)
The command tool will open
Type your command gradlew build --refresh-dependencies
Instead of removing your entire gradle cache, like some answers here are suggesting, you can delete the cache for a specific group or artifact id. I added the following function to my .bash_profile:
deleteGradleCache() {
local id=$1
if [ -z "$id" ]; then
echo "Please provide an group or artifact id to delete"
return 1
fi
find ~/.gradle/caches/ -type d -name "$id" -prune -exec rm -rf "{}" \; -print
}
Usage:
$ deleteGradleCache com.android.support
Then, on the next build or if you resync, gradle will re-download dependencies.
There is 2 ways to do that:
Using command line option to refresh dependenices cashe.
You can delete local cache where artefasts are caches by Gradle and trigger build
Using --refresh-dependencies option:
./gradlew build --refresh-dependencies
Short explanation --refresh-dependencies option tells Gradle to ignore all cached entries for resolved modules and artifacts.
Long explanantion
WIth –refresh-dependencies’ Gradle will always hit the remote server to check for updated artifacts: however, Gradle will avoid downloading a file where the same file already exists in the cache.
First Gradle will make a HEAD request and check if the server reports the file as unchanged since last time (if the ‘content-length’ and ‘last-modified’ are unchanged). In this case you’ll get the message: "Cached resource is up-to-date (lastModified: {})."
Next Gradle will determine the remote checksum if possible (either from the HEAD request or by downloading a ‘.sha1’ file)..
If this checksum matches another file already downloaded (from any repository), then Gradle will simply copy the file in the cache,
rather than re-downloading. In this case you’ll get the message: "“Found locally available resource with matching checksum: [{}, {}]”.
Using delete:
When you delete caches
rm -rf $HOME/.gradle/caches/
You just clean all the cached jars and sha1 sums and Gradle is in situation where there is no artifacts on your machine and has to download everything. Yes it will work 100% for the first time, but when another SNAPSHOT is released and it is part of your dependency tree you will be faced again in front of the choice to refresh or to purge the caches.
For Android Studio 3.4.1
Simply open the gradle tab (can be located on the right) and right-click on the parent in the list (should be called "Android"), then select "Refresh dependencies".
This should resolve your issue.
Seems change is changed to isChange for gradle version 6.3, kotlin version 1.3.70, Groovy 2.5.10
The working configuration is
implementation("com.sample:commons:1.0.0-SNAPSHOT") {
isChanging = true
}
Also, run this command to fetch the latest
./gradlew assemble --refresh-dependencies
This worked for me.
Make sure Gradle is not set to offline by unchecking button at File>Settings>Gradle>Offline Work.
Add this to the top level of your build.gradle, nice to have above dependencies
configurations.all {
resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}
I made sure my dependencies are written like this:
implementation('com.github.juanmendez:ThatDependency:ThatBranch-SNAPSHOT') {
changing = true
}
Thereafter, I open the Gradle panel in Android Studio and click the blue circle arrows button. I can always see my updates getting a new fresh copy.
If you are using Intellij, you can right click the root project and then select refresh gradle dependencies.
Mb I'm too late however my solution is for single repository. I think deleting ~/.gradle/* is overkill.
The problmem I've bumped into was that I was deleting directory where sources were and gradle was getting another version not from nexus.
To avoid that I run the next:
~/.gradle$ find . -type d -name 'group.plugins.awssdk'
./caches/modules-2/files-2.1/group.plugins.awssdk
./caches/modules-2/metadata-2.23/descriptors/group.plugins.awssdk
~/.gradle$ rm -r ./caches/modules-2/files-2.1/group.plugins.awssdk ./caches/modules-2/metadata-2.23/descriptors/group.plugins.awssdk
After that gradle is dragging files from nexus.
In my case none of the above worked, what I did was:
In build.gradle, commenting the dependencies related to the unresolved imports I had
Clicking "Sync Now"
Uncommenting what I just commented
Clicking "Sync Now" again
Then my imports were properly resolved again.
Deleting all the caches makes download all the dependacies again. so it take so long time and it is boring thing wait again again to re download all the dependancies.
How ever i could be able to resolve this below way.
Just delete groups which need to be refreshed.
Ex : if we want to refresh com.user.test group
rm -fr ~/.gradle/caches/modules-2/files-2.1/com.user.test/
then remove dependency from build.gradle and re add it.
then it will refresh dependencies what we want.
I think gradle 2.14.1 fixes the issue. The accepted answer is correct, but there is a bug in gradle with –refresh-dependencies. 2.14.1 fixes that.
See https://discuss.gradle.org/t/refresh-dependencies-should-use-cachechangingmodulesfor-0s/556
For the majority of cases, just simply re-building the project should do the trick. Sometimes you have to run ./gradlew build --refresh-dependencies as several answers have already mentioned (takes a long time, depending on how much dependencies you have). How ever, sometimes none of those will work: the dependency just won't get updated. Then, you can do this:
Remove dependency from your gradle file
Run / debug your project and wait for it to fail (with NonExistingClass reason)
Hit "build project" and wait for it to finish successfully
Run / debug once again
This is ridiculous and seems like madness, but I actually do use this procedure daily, simply because the dependency I need can be updated dozens of times and none of adequate solutions would have any effect.
If you are using eclipse and if you want force eclipse to re load dependencies you could try below command
gradlew clean cleaneclipse build eclipse --refresh-dependencies
Only a manual deletion of the specific dependency in the cache folder works... an artifactory built by a colleague in enterprise repo.
You can do it like this
https://marschall.github.io/2017/04/17/disabling-gradle-cache.html
To quote from Disabling the Gradle Build Cache
The Gradle build cache may be a great thing when you’re regularly building >large projects with Gradle. However when only occasionally building open source >projects it can quickly become large.
To disable the Gradle build cache add the following line to ~/.gradle/gradle.properties
org.gradle.caching=false
You can clean the existing cache with
rm -rf $HOME/.gradle/caches/
rm -rf $HOME/.gradle/wrapper/
delete this directory:
C:\Users\[username]\.gradle
You need to redownload it, so you can either manually download and replace the corrupted file and again sync your project . Go to this location
C:\users[username].gradle\wrapper\dist\gradle3.3-all\55gk2rcmfc6p2dg9u9ohc3hw9\gradle-3.3-all.zip
Here delete gradle3.3allzip and replace it by downloading again from this site
https://services.gradle.org/distributions/
Find the same file and download and paste it to that location
Then sync your project.
Hope it works for you too.
Related
I updated gradle locally by changing the version in my build.gradle file here:
wrapper {
gradleVersion = '5.6.1'
}
Next I was not able to build directly due to errors, but my IDE noticed that the version of gradle has changed and offered to install it through a popup. After that everything worked.
When I pushed my changes to my autodeployment tool it currently builds the project by executing:
call gradlew clean war
But I'm getting the same errors and this time there's no smart IDE to come to the rescue :D Therefore my question:
How can I make sure my gradle always updates to the version that is defined in build.gradle before trying to build?
The version of Gradle that is used by the wrapper script is the one defined in the file gradle/wrapper/gradle-wrapper.properties.
When you want to update Gradle, you could go manually changing that file, but this won't update the actual wrapper script and jar file. So it is a better practice to run ./gradlew wrapper, which will update gradle-wrapper.properties and, if needed, the other support files as well.
To tell the wrapper task which version you want to use upgrade to, you can either use a command line parameter, or do what you are doing and keep the version in the build.gradle file (this is always what I do as well).
I usually run the wrapper task twice: first to update the version and second to both download the new version and then regenerate the scripts from this new version.
Remember to commit all files changed by the wrapper task, which could be gradlew, gradlew.bat and the two files in the gradle/wrapper folder.
How does Gradle store downloaded jar files on the local file system? Maven stores them in the .m2 directory under USER_HOME, but where does Gradle store them? I checked the .gradle folder there, but saw only compiled scripts.
On Mac, Linux and Windows i.e. on all 3 of the major platforms, Gradle stores dependencies at:
~/.gradle/caches/modules-2/files-2.1
Gradle caches artifacts in USER_HOME/.gradle folder. The compiled scripts are usually in the .gradle folder in your project folder.
If you can't find the cache, maybe it's because you have not cached any artifacts yet. You can always see where Gradle has cached artifacts with a simple script:
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile 'com.google.guava:guava:12.0'
}
task showMeCache doLast() {
configurations.compileClasspath.each { println it }
}
Now if you run gradle showMeCache it should download the dependencies into the cache and print the full path.
In Windows 10 PC, it is saved at:
C:\Users\%USERNAME%\.gradle\caches\modules-2\files-2.1\
Gradle's local repository folder is:
$USER_HOME/.gradle/caches/modules-2/files-2.1
Defined dependencies will be loaded from remote repositories into gradle's local repository folder. For each loaded file, gradle will be create a new folder named with md5 value of the original file (pom,jar,..). Full path for the dependency file is made up from :
groupid + artifactid + version + FILE_MD5_VALUE + FILE_NAME
If our defined dependency is:
compile 'org.springframework:spring-jdbc:4.3.4.RELEASE'
Then the library will be loaded into :
/$USER_HOME/.gradle/caches/modules-2/files-2.1/org.springframework/spring-jdbc/4.3.4.RELEASE/42175d194cf6aa7c716c0887f30255e5c0a5262c/spring-jdbc-4.3.4.RELEASE.jar
In fact the cache location depends on the GRADLE_USER_HOME environment variable value.
By default, it is $USER_HOME/.gradle on Unix-OS based and %userprofile%.\gradle on Windows.
But if you set this variable, the cache directory would be located from this path.
And whatever the case, you should dig into caches\modules-2\files-2.1 to find the dependencies.
If you want your dependency files to be in some specific folder you can simply use a copy task for it. For Eg.
task copyDepJars(type: Copy) {
from configurations.compile
into 'C:\\Users\\athakur\\Desktop\\lib'
}
I am on windows,
You should be able find the dependencies inside
$USER_HOME.gradle\caches\artifacts-24\filestore
Many answers are correct!
I want to add that you can easily find your download location with
gradle --info build
like described in https://stackoverflow.com/a/54000767/4471199.
New downloaded artifacts will be shown in stdout:
Downloading https://plugins.gradle.org/m2/org/springframework/boot/spring-boot-parent/2.1.7.RELEASE/spring-boot-parent-2.1.7.RELEASE.pom to /tmp/gradle_download551283009937119777bin
In this case, I used the docker image gradle:5.6.2-jdk12.
As you can see, the docker container uses /tmp as download location.
You can use the gradle argument --project-cache-dir "/Users/whatever/.gradle/" to force the gradle cache directory.
In this way you can be darn sure you know what directory is being used (as well as create different caches for different projects)
I just stumbled onto this while searching for this answer. If you are using intellij, you can navigate to the file location, but opening the external lib folder in the project explorer, right clicking on the jar, and select Open Library Settings.
It took me a while to realize this, hence the additional answer. Hopefully it can save folks time. Note that if you are running sudo gradle the dependencies may not be in your home directory, even if sudo echo $HOME returns /Users/<my-non-root-user>/. On my Mac, Gradle was caching the dependencies in /private/var/root/.gradle/caches/.
In case it is an Android gradle project - you can find the android libraries below your $ANDROID_HOME/extras/android/m2repository folder
In android studio do the following steps to check the gradle downloaded jar file.
Set project structure view to "Project"
At bottom External library section available, expand it.
Here you can see downloaded jar files.
On my windows machine with "Buildship 2.0.2" plugin installed in eclipse, dependencies are stored :
$USER_HOME.gradle\caches\modules-2\files-2.1
For my case, I was using an Ivy repository, and my Gradle dependencies were stored in ~/.ivy2/.
I have an Eclipse setup with m2eclipse and subversive. I have imported a maven2 project from svn. But I get the error message that a whole bunch of artifacts are missing (for instance: Missing artifact org.springframework:spring-test:jar:3.0.1.RELEASE:test).
If I look in my repository I see the jar files there but they have an extra extension .lastUpdated. Why is maven appending .lastUpdated to the jars? And more importantly: how can I fix this?
There is no mention of the type lastUpdated in my POMs.
These files indicate to Maven that it attempted to obtain the archive by download, but was unsuccessful. In order to save bandwidth it will not attempt this again until a certain time period encoded in the file has elapsed. The command line switch -U force maven to perform the update before the retry period. This may be necessary if you attempted to build while disconnected from the network.
The method of removing the files works with most versions of maven, but since the files are internal mementos to maven, I would not recommend this method. There is no guarantee that this information is not referenced or held elsewhere and such manipulation can damage the system.
As rperez said, I use to delete all those .lastUpdated files. In Linux I have created a little script to keep it simple:
find -name \*.lastUpdated -exec rm -fv {} +
Just create a file with the previous content and put it on your local Maven repository. Usually it will be ~/.m2/repository.
I installed Maven2 and ran mvn compile from the command line. This seems to have resolved the problem
you might have a problem with some of the artifacts to be retrieved from the repository. for example spring framework has its own repository. this xtension is appended when the artifact cannot fully downloaded. add the spring framework repository to your pom or settings.xml, delete the folder that include the broken jars and start again
If you hit this problem and you're using Nexus, it might be the case that you have a routing rule defined, which is incorrect. I hit this myself and the files it was downloading were correctly named, at the proper URL-s it was looking at, but they were all with the .lastUpdated extension and an error message as contents.
Open your terminal, navigate to your Eclipse's project directory and run:
mvn install
If mvn install doesn't update your dependencies, then call it with a switch to force update:
mvn install -U
This is a much safer approach compared to tampering with maven files as you delete ".lastUpdated".
Use this command inside the .m2/repository dir to rename all files:
for file in `find . -iname *.lastUpdated`; do renamed=$(echo $file | rev | cut -c13- | rev); echo renaming: $file to $renamed; mv $file $renamed; done
This is usefull to not download all sources again.
This not work... The .jar is lost. :(
What I do when I encounter this issue:
Make sure you have the version of the latest 'maven-source-plugin' plugin:
https://maven.apache.org/plugins/maven-source-plugin/usage.html
$ mvn source:jar install
Now if the file *.lastUpdate exist in your local ~/.m2/repositories/your-lib/0.0.1/ directory you can just remove it then run the command above again.
This is a side-effect of a failure to successfully extract from the repository. To get the actual content you want into your repository, check for correct paths to the repository/repositories within your pom file, and resolve certificate/security issues, if any. It is almost invariably one or the other of these issues.
There is no need to delete the .lastUpdated entries, and doing so won't solve your problem.
I compiled a jar file in one project so it can be consumed in the 2nd one. I can see the jar file in .m2 folder. But in the 2nd project it complains about artifact not found.
I guess I have to force maven to update indices/cache something but don't know what exactly. Any tip, thanks.
Update: thanks for all good suggestions.
Turns out that the maven plugin (of IntelliJ) in the second project doesn't update its index. I use command line it compiled ok.
try using -U (aka --update-snapshots) when you run maven
And make sure the dependency definition is correct
You can also use this command on the command line:
mvn dependency:purge-local-repository clean install
If you are installing into local repository, there is no special index/cache update needed.
Make sure that:
You have installed the first artifact in your local repository properly. Simply copying the file to .m2 may not work as expected. Make sure you install it by mvn install
The dependency in 2nd project is setup correctly. Check on any typo in groupId/artifactId/version, or unmatched artifact type/classifier.
Even though this is an old question, I 've stumbled upon this issue multiple times and until now never figured out how to fix it. The update maven indices is a term coined by IntelliJ, and if it still doesn't work after you've compiled the first project, chances are that you are using 2 different maven installations.
Press CTRL+Shift+A to open up the Actions menu. Type Maven and go to Maven Settings. Check the Home Directory to use the same maven as you use via the command line
Click settings and search for "Repositories", then select the local repo and click "Update". That's all. This action meets my need.
If you are struggling with authenticating to a site, and Maven is caching the results, simply removing the meta-data about the site from the meta-data stash will force Maven to revisit the site.
gvim <local-git-repository>/commons-codec/resolver-status.properties
We would like to have a script that does "svn update" and if the depedency.gradle file is in that list of updates, we would like to run a task that ONLY updates dependencies so the developers machine is up to date. What would that task be? I don't see it when running "gradle tasks". Looking for an updatejars or something.
When we build our project, we don't want it to check for jar updates at all!!!! most because that only needs to be done in 2 situations which are #1 above and when someone is updating the dependency.gradle file themselves. For the second thing, they can just run "gradle updatejars" once I know the answer to question #1 that is.
Any ideas? I am just getting into gradle and we really want to keep a consistent environment where when we run our update script, it gets the source code AND the jars in one atomic sweep and we are no longer bothered by checking the repositories every build.
It would be nice to know how to do it by changing the build.gradle file if possible. If not, is there a command line option? (The build.gradle obviously would give me a command line option which is why I prefer that method as I could say compile does not depend on downloading jars).
Regarding the second question. As far as I understand, Gradle will not attempt to do remote lookups or try to download the jar if it is already in the local cache. This should be true for jars declared with a static version, e.g. testCompile 'junit:junit:4.10'.
If you have dynamic versions, e.g. 1.+ or 1.0-SNAPSHOT, etc. then Gradle has to do a check every now and then. You can fine tune the cache expiry for such dependencies.
To make sure Gradle does not do remote lookups you can also use --offline option. See this doc for details.
With regard to svn update, you have at least 3 options:
Try to use an SvnKit plugin for Gradle
Use the ant svn task (here's how to do svn checkout)
Run external command from Gradle. Use the ExecPlugin or just implement it yourself using Groovy API.
Looks like the 1st question I can do with the answer in this post
how to tell gradle to download all the source jars
so I can just gradle eclipse and it will download new jars and update my classpath...nice.