Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-1049

updated remote snapshot artifact during multiproject build causes exception

    Details

    • Type: Bug
    • Status: 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_d 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_d 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.
        Hide
        samoht Thomas Glaeser added a comment -

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

        Show
        samoht Thomas Glaeser added a comment - This has become a critical issue for us. Are there any setting/workarounds that could prevent this issue?
        Hide
        breskeby René Gröschke added a comment -

        just ran into this issue again with 0.9.1

        regards,

        Show
        breskeby René Gröschke added a comment - just ran into this issue again with 0.9.1 regards,
        Hide
        breskeby 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
        breskeby 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é
        Hide
        breskeby 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
        breskeby 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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development