Gradle

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
To raise new issues or bugs against Gradle, please use forums.gradle.org.
  • Gradle
  • GRADLE-629

Snapshot dependencies are not updated

  • Log In
  • Views
    • XML
    • Word
    • Printable

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.

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. Hide
    Zip Archive
    pomGeneration.zip
    16/Sep/09 6:04 AM
    3 kB
    Hans Dockter
    1. File
      pomGeneration/build.gradle 0.5 kB
    2. File
      __MACOSX/pomGeneration/._build.gradle 0.2 kB
    3. Java Source File
      pomGeneration/src/main/.../org/MyClass.java 0.0 kB
    4. XML File
      pomGeneration/src/main/.../WEB-INF/web.xml 0.0 kB
    Download Zip
    Show
    Zip Archive
    pomGeneration.zip
    16/Sep/09 6:04 AM
    3 kB
    Hans Dockter

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • History
  • Activity
  • TeamCity
  • Commits
  • Source
  • Reviews
Hans Dockter made changes - 13/Sep/09 6:10 AM
Field Original Value New Value
Fix Version/s 0.8 [ 15321 ]
Hans Dockter made changes - 16/Sep/09 5:38 AM
Status Open [ 1 ] In Progress [ 3 ]
Hide
Permalink
Hans Dockter added a comment - 16/Sep/09 6:03 AM

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 - 16/Sep/09 6:03 AM 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?
Hans Dockter made changes - 16/Sep/09 6:04 AM
Attachment pomGeneration.zip [ 44450 ]
Hide
Permalink
Peter Niederwieser added a comment - 16/Sep/09 6:48 AM

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 - 16/Sep/09 6:48 AM I publish the snapshot Jars with Maven. The Maven build always downloads new snapshots as expected, but Gradle doesn't.
Hide
Permalink
Hans Dockter added a comment - 16/Sep/09 7:14 AM

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 - 16/Sep/09 7:14 AM 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
Permalink
Hans Dockter added a comment - 16/Sep/09 7:17 AM

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 - 16/Sep/09 7:17 AM 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
Permalink
Hans Dockter added a comment - 16/Sep/09 7:22 AM

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 - 16/Sep/09 7:22 AM 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
Permalink
Peter Niederwieser added a comment - 16/Sep/09 10:12 AM

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 - 16/Sep/09 10:12 AM 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
Permalink
Hans Dockter added a comment - 16/Sep/09 10:21 AM

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

Show
Hans Dockter added a comment - 16/Sep/09 10:21 AM I have forgotten about uniqueVersion. I will try to find a way to make it work.
Hide
Permalink
Hans Dockter added a comment - 17/Sep/09 1:19 AM

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 - 17/Sep/09 1:19 AM 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
Permalink
Hans Dockter added a comment - 17/Sep/09 1:52 AM

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 - 17/Sep/09 1:52 AM 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
Permalink
Peter Niederwieser added a comment - 18/Sep/09 6:25 PM

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

Show
Peter Niederwieser added a comment - 18/Sep/09 6:25 PM You mean upload rights? Do you have a GMail account?
Hans Dockter made changes - 28/Sep/09 12:32 AM
Fix Version/s 0.9 [ 15625 ]
Fix Version/s 0.8 [ 15321 ]
Hide
Permalink
Peter Niederwieser added a comment - 23/Dec/09 9:48 AM

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

Show
Peter Niederwieser added a comment - 23/Dec/09 9:48 AM Still have this problem. Sounds like https://issues.apache.org/jira/browse/IVY-938
Hide
Permalink
Hans Dockter added a comment - 29/Dec/09 8:00 AM

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 - 29/Dec/09 8:00 AM 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
Permalink
Helmut Denk added a comment - 30/Dec/09 10:00 AM

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 - 30/Dec/09 10:00 AM 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
Permalink
Hans Dockter added a comment - 19/Apr/10 3:57 AM

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 - 19/Apr/10 3:57 AM 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.
Hans Dockter made changes - 19/Apr/10 3:57 AM
Fix Version/s 1.0 [ 15740 ]
Fix Version/s 0.9 [ 15625 ]
Hide
Permalink
Chris Hane added a comment - 03/Dec/10 8:38 AM

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 - 03/Dec/10 8:38 AM 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
Permalink
Thomas Glaeser added a comment - 03/Dec/10 1:30 PM

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 - 03/Dec/10 1:30 PM 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.
Adam Murdoch made changes - 09/Jan/11 9:55 PM
Assignee Hans Dockter [ hans_d ]
Contegix Support made changes - 19/Mar/11 9:23 AM
Project Import Sat Mar 19 09:23:24 CDT 2011 [ 1300544604020 ]
Hide
Permalink
Olivier Girardot added a comment - 18/Jun/11 12:51 PM - 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 - 18/Jun/11 12:51 PM - 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").
Adam Murdoch made changes - 18/Jul/11 7:17 PM
Fix Version/s 1.0 [ 10051 ]
Fix Version/s someday [ 10053 ]
Daz DeBoer made changes - 03/Aug/11 3:29 PM
Workflow jira [ 12791 ] jira with pivotal tracker [ 14371 ]
Daz DeBoer made changes - 27/Dec/11 5:37 PM
Assignee Daz DeBoer [ daz ]
Hide
Permalink
Daz DeBoer added a comment - 25/Jan/12 7:23 PM

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 - 25/Jan/12 7:23 PM 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.
Daz DeBoer made changes - 25/Jan/12 7:23 PM
Resolution Fixed [ 1 ]
Fix Version/s someday [ 10053 ]
Fix Version/s 1.0-milestone-8 [ 10165 ]
Status In Progress [ 3 ] Resolved [ 5 ]
Peter Niederwieser made changes - 13/Feb/12 7:54 PM
Status Resolved [ 5 ] Closed [ 6 ]
Luke Daley made changes - 03/Jan/13 5:08 AM
Workflow jira with pivotal tracker [ 14371 ] jira with pivotal tracker (no resolved, only closed) [ 16216 ]
Luke Daley made changes - 04/Jan/13 5:09 AM
Status Closed [ 6 ] Resolved [ 5 ]
Workflow jira with pivotal tracker (no resolved, only closed) [ 16216 ] Copy of jira with pivotal tracker (no closed, only resolved) [ 18887 ]
Unable to get TeamCity builds: No active plugin license is found! Please visit http://stiltsoft.com/teamcity for details

People

  • Assignee:
    Daz DeBoer
    Reporter:
    Peter Niederwieser
Vote (8)
Watch (11)

Dates

  • Created:
    09/Sep/09 7:08 PM
    Updated:
    04/Jan/13 5:09 AM
    Resolved:
    25/Jan/12 7:23 PM
  • Atlassian JIRA (v5.0.3#729-sha1:bf569e4)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Gradle. Try JIRA - bug tracking software for your team.