updated remote snapshot artifact during multiproject build causes exception

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Resolution: Fixed
  • Affects Version/s: 0.9
  • Fix Version/s: 1.0-milestone-8

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Hans Dockter added a comment -

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.

Show
Hans Dockter added a comment - 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.
Hans Dockter made changes -
Field Original Value New Value
Fix Version/s 1.0 [ 15740 ]
Hide
Permalink
Thomas Glaeser added a comment -

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

Show
Thomas Glaeser added a comment - This has become a critical issue for us. Are there any setting/workarounds that could prevent this issue?
Adam Murdoch made changes -
Assignee Hans Dockter [ hans_d ]
Hide
Permalink
René Gröschke added a comment -

just ran into this issue again with 0.9.1

regards,

Show
René Gröschke added a comment - just ran into this issue again with 0.9.1 regards,
Hide
Permalink
René Gröschke added a comment -

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é

Show
René Gröschke added a comment - 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é
Hans Dockter made changes -
Fix Version/s 1.0 [ 15740 ]
Fix Version/s 1.0-milestone-1 [ 17084 ]
Adam Murdoch made changes -
Fix Version/s 1.0-milestone-1 [ 17084 ]
Fix Version/s 1.0-milestone-2 [ 17051 ]
Hide
Permalink
René Gröschke added a comment -

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.

Show
René Gröschke added a comment - 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.
Contegix Support made changes -
Project Import Sat Mar 19 09:23:24 CDT 2011 [ 1300544604020 ]
Adam Murdoch made changes -
Fix Version/s 1.0-milestone-2 [ 10049 ]
Fix Version/s 1.0-milestone-3 [ 10050 ]
Adam Murdoch made changes -
Fix Version/s 1.0-milestone-3 [ 10050 ]
Fix Version/s 1.0-milestone-4 [ 10060 ]
Adam Murdoch made changes -
Fix Version/s 1.0-milestone-4 [ 10060 ]
Fix Version/s 1.0 [ 10051 ]
Adam Murdoch made changes -
Fix Version/s 1.0 [ 10051 ]
Fix Version/s someday [ 10053 ]
Daz DeBoer made changes -
Workflow jira [ 12826 ] jira with pivotal tracker [ 14763 ]
Adam Murdoch made changes -
Fix Version/s someday [ 10053 ]
Fix Version/s 1.0-milestone-7 [ 10164 ]
Daz DeBoer made changes -
Assignee Daz DeBoer [ daz ]
Daz DeBoer made changes -
Fix Version/s 1.0-milestone-7 [ 10164 ]
Fix Version/s 1.0-milestone-8 [ 10165 ]
Daz DeBoer made changes -
Resolution Fixed [ 1 ]
Status Open [ 1 ] Resolved [ 5 ]
Peter Niederwieser made changes -
Status Resolved [ 5 ] Closed [ 6 ]
Luke Daley made changes -
Workflow jira with pivotal tracker [ 14763 ] jira with pivotal tracker (no resolved, only closed) [ 17072 ]
Luke Daley made changes -
Status Closed [ 6 ] Resolved [ 5 ]
Workflow jira with pivotal tracker (no resolved, only closed) [ 17072 ] Copy of jira with pivotal tracker (no closed, only resolved) [ 19777 ]
Unable to get TeamCity builds: No active plugin license is found! Please visit http://stiltsoft.com/teamcity for details

People

  • Assignee:
    Daz DeBoer
    Reporter:
    René Gröschke
Vote (2)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: