[GRADLE-1049] updated remote snapshot artifact during multiproject build causes exception Created: 22/Jul/10  Updated: 04/Jan/13  Resolved: 29/Jan/12

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: 1.0-milestone-8

Type: Bug
Reporter: René Gröschke (Inactive) Assignee: Daz DeBoer
Resolution: Fixed Votes: 2


 Description   

If you run a multiproject build and different subprojects have dependencies to the same artifact that is stored in a remote repository, the build fails if the remote artifact was updated while running the multiproject.

The stacktrace looks like this:
{{
09:14:09.609 [main] ERROR org.gradle.logging.IvyLoggingAdaper - :::: ERRORS
09:14:09.609 [main] ERROR org.gradle.logging.IvyLoggingAdaper - Couldn't delete outdated artifact from cache: C:\Dokumente und Einstellungen\Hudson\.gradle\cache\org.acme\SimpleUserService\jars\SimpleUserService-0.8-SNAPSHOT.jar

09:14:09.609 [main] ERROR org.gradle.logging.IvyLoggingAdaper - Couldn't delete outdated artifact from cache: C:\Dokumente und Einstellungen\Hudson\.gradle\cache\org.acme\SimpleConfiguration\jars\SimpleConfiguration-0.8-SNAPSHOT.jar
09:14:09.609 [main] ERROR org.gradle.logging.IvyLoggingAdaper - Couldn't delete outdated artifact from cache: C:\Dokumente und Einstellungen\Hudson\.gradle\cache\org.acme\PersistenceLayer\jars\PersistenceLayer-0.8-SNAPSHOT.jar

09:14:09.609 [main] INFO org.gradle.logging.IvyLoggingAdaper -
:: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
09:14:09.609 [main] DEBUG o.g.a.i.a.i.DefaultIvyDependencyResolver - Timing: Ivy resolve took 8.515 secs
09:14:09.625 [main] DEBUG org.gradle.api.tasks.testing.Test - Finished tests
09:14:09.625 [main] INFO o.g.logging.ProgressLoggingBridge -
09:14:09.625 [main] DEBUG o.g.a.i.tasks.SkipTaskExecuter - Finished executing task ':Kernel:test'
09:14:09.625 [main] INFO o.g.logging.ProgressLoggingBridge -
09:14:09.719 [main] ERROR org.gradle.launcher.Main -
FAILURE: Build failed with an exception.
}}

Gradle should always resolve a dynamic dependency to exactly the
same set of artifacts during the entire life of the build, regardless of
which project or configuration the dependency is included in.

 Comments   
Comment by Hans Dockter [ 22/Jul/10 ]

Your issue should be fixed in trunk for all practical purposes (I guess you are using preview-3). Ivy (and thus preview-3) always checks Maven snapshots for being up to date. This can cause trouble and is a big performance issue. In trunk the up to date check for snapshots is now configurable (default is daily). Unless you are doing a build around midnight, everything should work fine.

But I don't close the issue as we want to have a more bullet proof solution for one instance of a multi-project build.

Comment by Thomas Glaeser [ 03/Dec/10 ]

This has become a critical issue for us. Are there any setting/workarounds that could prevent this issue?

Comment by René Gröschke (Inactive) [ 28/Jan/11 ]

just ran into this issue again with 0.9.1

regards,

Comment by René Gröschke (Inactive) [ 31/Jan/11 ]

Hi there,
since this is still a blocker for one of our projects, I had a deeper look at this problem. It seems that the DefaultRepositoryCacheManager of Ivy caches the dependency descriptor after it is loaded from "~/.gradle/cache/.." for the first time. After the first download the cached descriptor isn't invalidated, so the lastModified property of the descriptor still points to a date before the first download.
To avoid a second download and disable the caching of the ivy files, I added the following (dirty) code to the GradleIBiblioResolver:
—

@Override
protected ResolvedModuleRevision findModuleInCache(DependencyDescriptor dd, ResolveData data)

{ ((DefaultRepositoryCacheManager)getRepositoryCacheManager()).setMemorySize(0); ... }

}}
—

Is there a more elegant way to customize Ivys DefaultRepositoryCacheManager via gradle?
regards,
René

Comment by René Gröschke (Inactive) [ 02/Mar/11 ]

this root cause of this bug seems to be the bug described in GRADLE-600. I used the workarround above to avoid GRADLE-600 and this issue here.

Generated at Wed Jun 30 11:45:36 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.