Gradle
  1. Gradle
  2. GRADLE-629

Snapshot dependencies are not updated

    Details

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

      Description

      spock-example has a snapshot dependency on spock-core. However, this dependency is never updated, unless I delete ~/.gradle/cache.
      To reproduce, check out http://spock.googlecode.com/svn/trunk/, and build sub-project spock-example. I also tried with a standalone project, and the result was the same.

        Activity

        Hide
        Hans Dockter
        added a comment -

        I'm wondering if your repository is correct regarding metadata.xml and existing snapshot jars. Hwo do you publish the spock-core to the maven repository. I have attached a simple Gradle project which publishes a snapshot and then downloads it again. It is always retrieving the latest snapshot. How does Maven behave?

        Show
        Hans Dockter
        added a comment - I'm wondering if your repository is correct regarding metadata.xml and existing snapshot jars. Hwo do you publish the spock-core to the maven repository. I have attached a simple Gradle project which publishes a snapshot and then downloads it again. It is always retrieving the latest snapshot. How does Maven behave?
        Hide
        Peter Niederwieser
        added a comment -

        I publish the snapshot Jars with Maven. The Maven build always downloads new snapshots as expected, but Gradle doesn't.

        Show
        Peter Niederwieser
        added a comment - I publish the snapshot Jars with Maven. The Maven build always downloads new snapshots as expected, but Gradle doesn't.
        Hide
        Hans Dockter
        added a comment -

        Your snapshot repository looks strange. Usually SNAPSHOT is replaced with a timestamp in the remote repository. See for example: http://snapshots.jboss.org/maven2/javax/persistence/jpa-api/2.0.Beta1-SNAPSHOT/. So I'm wondering if there is a problem with your deployment, despite the fact that Maven seems to swallow this.

        Show
        Hans Dockter
        added a comment - Your snapshot repository looks strange. Usually SNAPSHOT is replaced with a timestamp in the remote repository. See for example: http://snapshots.jboss.org/maven2/javax/persistence/jpa-api/2.0.Beta1-SNAPSHOT/ . So I'm wondering if there is a problem with your deployment, despite the fact that Maven seems to swallow this.
        Hide
        Hans Dockter
        added a comment -

        I forgot to mention that we rely on the Ivy maven compatibility for reading from Maven repositories. They use their own code to read from a Maven repository. So the behavior can differ from Maven. Gradle uses Maven technology to publish to remote repositories, so for publishing we are 100 percent compatible.

        Show
        Hans Dockter
        added a comment - I forgot to mention that we rely on the Ivy maven compatibility for reading from Maven repositories. They use their own code to read from a Maven repository. So the behavior can differ from Maven. Gradle uses Maven technology to publish to remote repositories, so for publishing we are 100 percent compatible.
        Hide
        Hans Dockter
        added a comment -

        What you could also try is not to use a Maven repository but a normal URLResolver and then changing it to true for the spock-core dependency. For a repository like your one that should work. For a normal snapshot repository this would not work (as the SNAPSHOT bit is replaced). You might also set the checkModified attribute of the URLResolver to true.

        Show
        Hans Dockter
        added a comment - What you could also try is not to use a Maven repository but a normal URLResolver and then changing it to true for the spock-core dependency. For a repository like your one that should work. For a normal snapshot repository this would not work (as the SNAPSHOT bit is replaced). You might also set the checkModified attribute of the URLResolver to true.
        Hide
        Peter Niederwieser
        added a comment -

        Sounds like another Maven/Ivy incompatibility then. Maven makes it configurable whether to keep all snapshots in a repository or just the last one. Since I find it rather meaningless to keep all snapshots around, I always use the latter option. The config element is <snapshotRepository> ... <uniqueVersion>false</uniqueVersion> </snapshotRepository>.

        Show
        Peter Niederwieser
        added a comment - Sounds like another Maven/Ivy incompatibility then. Maven makes it configurable whether to keep all snapshots in a repository or just the last one. Since I find it rather meaningless to keep all snapshots around, I always use the latter option. The config element is <snapshotRepository> ... <uniqueVersion>false</uniqueVersion> </snapshotRepository>.
        Hide
        Hans Dockter
        added a comment -

        I have forgotten about uniqueVersion. I will try to find a way to make it work.

        Show
        Hans Dockter
        added a comment - I have forgotten about uniqueVersion. I will try to find a way to make it work.
        Hide
        Hans Dockter
        added a comment -

        I have modified the attached example. I'm now deploying with uniqueVersion=false. The script deploys to a file URL which is also a Tomcat Webapp folder. The dependencies are read via http. Gradle behaves correctly. The dependencies are downloaded as soon as a new version of the snapshot is deployed. This means I can't reproduce your problem. I will try now to use some truly remote repository. It might be related to how the file timestamp information is provided by the server.

        Show
        Hans Dockter
        added a comment - I have modified the attached example. I'm now deploying with uniqueVersion=false. The script deploys to a file URL which is also a Tomcat Webapp folder. The dependencies are read via http. Gradle behaves correctly. The dependencies are downloaded as soon as a new version of the snapshot is deployed. This means I can't reproduce your problem. I will try now to use some truly remote repository. It might be related to how the file timestamp information is provided by the server.
        Hide
        Hans Dockter
        added a comment -

        I have tried it now with a remote repository and everything works for me. I have deployed via SCP with uniqueVersion=false. Gradle figures out when to download the newest snapshot and when not. So I guess we need to work with your repo to figure this out. Could you give me access rights to a testrepo on your machine?

        Show
        Hans Dockter
        added a comment - I have tried it now with a remote repository and everything works for me. I have deployed via SCP with uniqueVersion=false. Gradle figures out when to download the newest snapshot and when not. So I guess we need to work with your repo to figure this out. Could you give me access rights to a testrepo on your machine?
        Hide
        Peter Niederwieser
        added a comment -

        You mean upload rights? Do you have a GMail account?

        Show
        Peter Niederwieser
        added a comment - You mean upload rights? Do you have a GMail account?
        Hide
        Peter Niederwieser
        added a comment -

        Still have this problem. Sounds like https://issues.apache.org/jira/browse/IVY-938

        Show
        Peter Niederwieser
        added a comment - Still have this problem. Sounds like https://issues.apache.org/jira/browse/IVY-938
        Hide
        Hans Dockter
        added a comment -

        Thanks for figuring this out. We might use an ivy snapshot with the fix for the 0.9 release. I'm still somehow confused about this issue as I could not reproduce it.

        Show
        Hans Dockter
        added a comment - Thanks for figuring this out. We might use an ivy snapshot with the fix for the 0.9 release. I'm still somehow confused about this issue as I could not reproduce it.
        Hide
        Helmut Denk
        added a comment -

        i had such problems with ivy versions pre 2.0 too (i
        am not up to date with ivy now).

        those kind of problems did drive me to split-up
        the cache and have a separate cache for snapshots.
        that way i can cleanout the snapshot-cache without
        loosing all cached thirtparty-libs.

        if i remember it right, i found out, that the problem had to
        do with using multiple SNAPSHOT-repos in a chain. ivy caches
        artifact-metadata and refuses to take a newer SNAPSHOT-artifact
        from a different repo until the SNAPSHOT-cache is cleared.

        just a note ... it may not help or be related to the actual
        problem.

        Show
        Helmut Denk
        added a comment - i had such problems with ivy versions pre 2.0 too (i am not up to date with ivy now). those kind of problems did drive me to split-up the cache and have a separate cache for snapshots. that way i can cleanout the snapshot-cache without loosing all cached thirtparty-libs. if i remember it right, i found out, that the problem had to do with using multiple SNAPSHOT-repos in a chain. ivy caches artifact-metadata and refuses to take a newer SNAPSHOT-artifact from a different repo until the SNAPSHOT-cache is cleared. just a note ... it may not help or be related to the actual problem.
        Hide
        Hans Dockter
        added a comment -

        There is no Ivy release containing a fix for this issue yet. Therefore I postpone it to 1.0. In any case we want to use a native Maven resolver for 1.0 which should fix that.

        Show
        Hans Dockter
        added a comment - There is no Ivy release containing a fix for this issue yet. Therefore I postpone it to 1.0. In any case we want to use a native Maven resolver for 1.0 which should fix that.
        Hide
        Chris Hane
        added a comment -

        There are two items in this issue. One is uploading a snapshot to a maven repository and the second is downloading the snapshot as a dependency. The first seems to be solved in that thread. The second is an open item that seems to be waiting on something to happen in ivy.

        I was able to have gradle.09-rc3 check for and download new snapshots (from an artifactory repo) with the following dependency definition.

        compile(group: 'com.itsolut', name: 'common', version: '3.0-SNAPSHOT')

        { changing=true }

        The key was the "changing=true". Once that was added, the dependency was download when it was changed in the repo.

        Show
        Chris Hane
        added a comment - There are two items in this issue. One is uploading a snapshot to a maven repository and the second is downloading the snapshot as a dependency. The first seems to be solved in that thread. The second is an open item that seems to be waiting on something to happen in ivy. I was able to have gradle.09-rc3 check for and download new snapshots (from an artifactory repo) with the following dependency definition. compile(group: 'com.itsolut', name: 'common', version: '3.0-SNAPSHOT') { changing=true } The key was the "changing=true". Once that was added, the dependency was download when it was changed in the repo.
        Hide
        Thomas Glaeser
        added a comment -

        Following download setting are working for me.

        Setting checkmodified to true and setting the changingMatcher and changingPattern properties at the repository level:

        repositories {
            def baseUrl = 'http://my.repo.url'
            add(new org.apache.ivy.plugins.resolver.URLResolver()) {
                name = 'myRepo'
                m2compatible = true
                usepoms = false
                addIvyPattern(      baseUrl + '/[organisation]/[module]/[revision]/ivy(-[revision]).xml')
                addArtifactPattern( baseUrl + '/[organisation]/[module]/[revision]/[artifact](-[appendix])(-[revision])(-[classifier]).[ext]')
                descriptor = 'optional'
                checkmodified = true
                changingMatcher = 'regexp'
                changingPattern = '.*-SNAPSHOT*'
            }
        }
        

        in conjunction with Ivy's status version matcher latest.integration:

        dependencies {
            compile(
                'my.group.id:my-artifact-name:latest.integration',
            )
        }
        

        I tested with 0.9-rc-2 and 0.9-rc-3.

        Show
        Thomas Glaeser
        added a comment - Following download setting are working for me. Setting checkmodified to true and setting the changingMatcher and changingPattern properties at the repository level: repositories { def baseUrl = 'http://my.repo.url' add(new org.apache.ivy.plugins.resolver.URLResolver()) { name = 'myRepo' m2compatible = true usepoms = false addIvyPattern( baseUrl + '/[organisation]/[module]/[revision]/ivy(-[revision]).xml') addArtifactPattern( baseUrl + '/[organisation]/[module]/[revision]/[artifact](-[appendix])(-[revision])(-[classifier]).[ext]') descriptor = 'optional' checkmodified = true changingMatcher = 'regexp' changingPattern = '.*-SNAPSHOT*' } } in conjunction with Ivy's status version matcher latest.integration : dependencies { compile( 'my.group.id:my-artifact-name:latest.integration', ) } I tested with 0.9-rc-2 and 0.9-rc-3.
        Hide
        Olivier Girardot
        added a comment - - edited

        As specified in last comment,
        using

        changingPattern = '.*-SNAPSHOT*' 

        worked for us
        and was tested with 1.0-milestone-3 and future milestone-4 (HEAD being "af75bd0183613d1fa58c2f8294632ba117c1ffe1").

        Show
        Olivier Girardot
        added a comment - - edited As specified in last comment, using changingPattern = '.*-SNAPSHOT*' worked for us and was tested with 1.0-milestone-3 and future milestone-4 (HEAD being "af75bd0183613d1fa58c2f8294632ba117c1ffe1").
        Hide
        Daz DeBoer
        added a comment -

        So much has changed in snapshot caching since this bug was reported, I'm resolving it. There were (unrelated) issues around snapshot updating in Milestone 7, but they have been fixed for Milestone 8.

        Show
        Daz DeBoer
        added a comment - So much has changed in snapshot caching since this bug was reported, I'm resolving it. There were (unrelated) issues around snapshot updating in Milestone 7, but they have been fixed for Milestone 8.

          People

          • Assignee:
            Daz DeBoer
            Reporter:
            Peter Niederwieser
          • Votes:
            8 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: