Gradle
  1. Gradle
  2. GRADLE-1049

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

        Hide
        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
        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
        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
        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-milestone-1 [ 17084 ]
        Fix Version/s 1.0 [ 15740 ]
        Adam Murdoch
        made changes -
        Fix Version/s 1.0-milestone-2 [ 17051 ]
        Fix Version/s 1.0-milestone-1 [ 17084 ]
        Hide
        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-3 [ 10050 ]
        Fix Version/s 1.0-milestone-2 [ 10049 ]
        Adam Murdoch
        made changes -
        Fix Version/s 1.0-milestone-4 [ 10060 ]
        Fix Version/s 1.0-milestone-3 [ 10050 ]
        Adam Murdoch
        made changes -
        Fix Version/s 1.0 [ 10051 ]
        Fix Version/s 1.0-milestone-4 [ 10060 ]
        Adam Murdoch
        made changes -
        Fix Version/s someday [ 10053 ]
        Fix Version/s 1.0 [ 10051 ]
        Daz DeBoer
        made changes -
        Workflow jira [ 12826 ] jira with pivotal tracker [ 14763 ]
        Adam Murdoch
        made changes -
        Fix Version/s 1.0-milestone-7 [ 10164 ]
        Fix Version/s someday [ 10053 ]
        Daz DeBoer
        made changes -
        Assignee Daz DeBoer [ daz ]
        Daz DeBoer
        made changes -
        Fix Version/s 1.0-milestone-8 [ 10165 ]
        Fix Version/s 1.0-milestone-7 [ 10164 ]
        Daz DeBoer
        made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        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 -
        Workflow jira with pivotal tracker (no resolved, only closed) [ 17072 ] Copy of jira with pivotal tracker (no closed, only resolved) [ 19777 ]
        Status Closed [ 6 ] Resolved [ 5 ]

          People

          • Assignee:
            Daz DeBoer
            Reporter:
            René Gröschke
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: