https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
e
For more context, we currently solve the problem above by restarting the machine
v
What is the reason to redownload, especially regularly? Is some dependency changing white the version stays the same? If so, you can define it as changing version, and you can configure the time how often Gradle looks for changes of changing versions.
👍 1
e
Is some dependency changing white the version stays the same?
Correct.
If so, you can define it as changing version, and you can configure the time how often Gradle looks for changes of changing versions.
I’m aware of this feature, but we want to do it on-demand too. Also, some question here. When will Gradle download the dependency? Is it when the checksum is different
v
Probably, but I don't know the exact details. And I'm not aware of a way to just refresh one dependency besides deleting it from the cache. With snapshot versions each individual one has also a timestamp based explicit version you could use, but that's probably not what you want.
e
True, thanks for the suggestion. Anyway do you know about the cache/lock issue?
but this is sometime unreliable as Gradle will download previous artifact not the new one.
v
I guess what is the "latest" is stored somewhere that you don't throw away, but I don't know exactly
e
That make sense since if we’re only removing the 
files-*
, it will download the version matching with the metadata, that’s why my assumption is also a cache or lock file. Tagging @no in here in case he knows something 👀
n
I think the problem to solve is why this dependency is changing while the version stays the same.
e
Correct, but it’s currently kinda hard for us and bandwidth is limited. For the context it’s a dynamic version generated from checksum, but the checksum do not include the dependency tree because we need to have version before project evaluation. As for why, it’s related to this forked repository.
n
Thanks for letting me know. I deleted the fork since I cannot recommend this approach.
e
I kinda assume you won't, I got it from the original since it's in my org. I'm always open for a new approach and we're a GE customer too, but this currently works for us.
n
What is the problem you are trying to solve?
e
Before going further, just to confirm, there's no lock file or other cache? If that's the case, can we file this as a bug?
n
There are several caches in Gradle.
I'm not sure I understand the issue. An 
aar
file does not contain version information. Therefore I cannot recommend this approach.
e
It's related but not 1:1 implementation. We're using maven artifact which has POM file
n
I see. To be honest, I'm not exactly sure what the issue is. There are many different caches in Gradle. Without knowing what the issue you are currently experiencing is, I cannot point you to the right place.
e
The error is on my part. I will get back to this thread later with more detailed issue on my part hopefully with finding in our build scans data also.
Hi @no, I’m back, just analyzed the build scans when we debugged the issue but there’s no irregularity to it. But I got some data that might help So here’s the issue: • Our content and version dependencies are out of sync due to versions are currently generated from module checksum, so ABI related changes will cause an issue. (e.g kotlin data class) • To refresh/re-download the dependency, we remove the artifact from Gradle’s cache (both files and metadata) and rebuild the app with assemble task • The issue arose where removing the cache did not download the updated file from our repository and the old file persisted. This was determined by checking the sha1 hash in the cache directory. (e.g 
modules-2/files-2.1/com.example/module/version/123asd123123123
) also verified by having the same runtime crash from the ABI mismatch. • By looking at the build scan in 
Network Activity
tab, the dependency was actually download (image attached), and the Daemon also shows 0 for both previous builds and others daemon number. • This issue as later resolved by restarting the machine Please note that issue is intermittent, but once the issue arose, restarting a machine always fix it.
n
Does killing the daemon also resolve it?
v
I almost asked the same, then have seen
the Daemon also shows 0 for both previous builds and others daemon number
so I guessed there is nothing to kill 🙂
✅ 1
e
Yes, manually killing a running daemon with 
./gradlew --stop
also doesn’t work.
Open in Slack
PreviousNext
Powered by