Gradle
  1. Gradle
  2. GRADLE-1049

updated remote snapshot artifact during multiproject build causes exception

    Details

    • Type: Bug 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 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.
        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?
        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é
        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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development