[GRADLE-629] Snapshot dependencies are not updated Created: 09/Sep/09  Updated: 04/Jan/13  Resolved: 25/Jan/12

Status: Resolved
Project: Gradle
Affects Version/s: 0.7
Fix Version/s: 1.0-milestone-8

Type: Bug
Reporter: Peter Niederwieser Assignee: Daz DeBoer
Resolution: Fixed Votes: 8

Attachments: Zip Archive pomGeneration.zip    

 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.



 Comments   
Comment by Hans Dockter [ 16/Sep/09 ]

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?

Comment by Peter Niederwieser [ 16/Sep/09 ]

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

Comment by Hans Dockter [ 16/Sep/09 ]

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.

Comment by Hans Dockter [ 16/Sep/09 ]

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.

Comment by Hans Dockter [ 16/Sep/09 ]

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.

Comment by Peter Niederwieser [ 16/Sep/09 ]

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>.

Comment by Hans Dockter [ 16/Sep/09 ]

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

Comment by Hans Dockter [ 17/Sep/09 ]

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.

Comment by Hans Dockter [ 17/Sep/09 ]

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?

Comment by Peter Niederwieser [ 18/Sep/09 ]

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

Comment by Peter Niederwieser [ 23/Dec/09 ]

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

Comment by Hans Dockter [ 29/Dec/09 ]

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.

Comment by Helmut Denk [ 30/Dec/09 ]

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.

Comment by Hans Dockter [ 19/Apr/10 ]

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.

Comment by Chris Hane [ 03/Dec/10 ]

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.

Comment by Thomas Glaeser [ 03/Dec/10 ]

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.

Comment by Olivier Girardot [ 18/Jun/11 ]

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").

Comment by Daz DeBoer [ 25/Jan/12 ]

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.

Generated at Wed Jun 30 11:34:49 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.