[GRADLE-3139] Eclipse plugin doesn't honour cache timeouts for snapshot source/javadoc artifacts Created: 24/Jul/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 3


 Description   

We are having trouble to get our sources artifacts correctly updated with the eclipse plugin for snapshots version. Our projects are in Java and the repository is a maven 2 layout. Snapshot caching is disabled. Sources artifacts are downloaded once per version of dependency are further updates (snapshots) are not downloaded.

------------------------------------------------------------
Gradle 1.12
------------------------------------------------------------

Build time: 2014-04-29 09:24:31 UTC
Build number: none
Revision: a831fa866d46cbee94e61a09af15f9dd95987421

Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
Ivy: 2.2.0
JVM: 1.7.0_10 (Oracle Corporation 23.6-b04)
OS: Windows 7 6.1 amd64

The following example involved two projects : eclipse-java and mongo-java. The eclipse task is invoke in the eclipse-java project that depend on mongo-java artifact. This is not a project dependency.

The problem is 100% reproducible with those steps for direct dependency or transitive dependency as well.

Build.gradle (simplify)

sourceCompatibility = 1.7
targetCompatibility = 1.7

configurations.all {
resolutionStrategy {
cacheDynamicVersionsFor 0, "seconds"
cacheChangingModulesFor 0, 'seconds'
}
}

dependencies {
// transitive way
compile group: 'com.test.eclipse', name: 'eclipse-java', version: '5.0.1.Beta3-SNAPSHOT'

// direct dependency
//compile group: 'com.test.mongo', name: 'mongo-java', version: '5.0.1.Beta3-SNAPSHOT'
}

//...

Repro steps :

  • go to the artifact/version folder of mongo-java in the gradle cache
  • delete all folders
  • run "gradlew eclipse -x test" on eclipse-java
    • refresh mongo-java cache folder
    • in that folder you should see 3 folders (one for jar, sources and pom)
  • upload mongo-java dependency on the repository
    • jar, sources, javadoc and pom are transferred
    • md5 and sha-1 checksum changed (we validated on artifactory)
  • "run gradlew eclipse -x test"
    • in the cache folder you should see 4 folders (2 for jar, 1 sources and 1 pom)
    • jar artifact is up-to-date
    • sources jar weren't updated

 Comments   
Comment by Gradle Forums [ 24/Jul/14 ]

I have the same problem, must often wipe out the .gradle folder that contains the cache of my artifacts.

Comment by KwonNam Son [ 03/Feb/15 ]

Same in IntelliJ IDEA 13,14

Comment by Henry Tung [ 16/Mar/15 ]

For those interested in this, the root cause is that DefaultConfigurationContainer.detachedConfiguration() does not respect/copy ResolutionStrategy since it is not scoped to a single configuration.

Both the Idea and Eclipse IDE plugins use IdeDependenciesExtractor AFAIK, which collects and organizes artifact dependencies without the scope of their original source configuration (see IdeDependenciesExtractor.extractRepoFileDependencies). This forces DefaultArtifactResolutionQuery.execute() to use a detachedConfiguration instead and hence a default ResolutionStrategy, which is not outwardly configurable.

As far as I can tell, IdeDependenciesExtractor should instead copy the plusConfigurations and then prune dependencies found in the minusConfigurations, returning a collection of the resulting copied configurations, since these will inherit their original ResolutionStrategy properly.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:41:00 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.