[GRADLE-3015] Incorrect artifact file resolved from cache for buildscript classpath Created: 04/Feb/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: | 5 |
| Issue Links: |
|
||||||||
| Description |
|
The crux of the issue:
[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleVersionRepository] Found artifact 'org.apache.bcel:bcel:2.1:bcel.jar' in resolver cache: C:\Users\\.gradle\caches\modules-2\files-2.1\com.google.protobuf\protoc\2.5.0\267b2e8ac1b38481e25253da72b4302d10810029\protoc-2.5.0-win32.exe
The original forum issue: While digging into the problem, it turned out that we do have wrong files on the buildscript classpath.
buildscript {
repositories {
maven { url repositoryBaseURL + '/repo1' }
maven { url repositoryBaseURL + '/anotherRepo' }
mavenLocal()
}
dependencies {
classpath "org.apache.bcel:bcel:2.1"
classpath "c.c.t:myPlugin:2.6.2"
}
println "classpath: " + buildscript.configurations.classpath.files
}
..
The script above leads to the following output: ~/.gradle/caches/artifacts-26/filestore/org.apache.bcel/bcel/2.1/jar/eab80d0721bf3057066e09d80e7fa8069fda9c87/bcel-2.1.jar "c.c.a.anotherProject-0.0.0.20131129-085741.5124.jar" is on the classpath (and has nothing to do with "myPlugin"), but we never specified this one. Additionally, "myPlugin" is missing completely on the classpath. After cleaning the gradle cache, the build does not fail any longer and we do get the expected files on buildscript classpath. (Note: we are using gradle 1.8) |
| Comments |
| Comment by Gradle Forums [ 04/Feb/14 ] |
|
... happened once again (using gradle 1.9 now). This time the other dependency specified in the buildscript section was missing on the actual buildscript classpath. |
| Comment by Gradle Forums [ 04/Feb/14 ] |
|
Hard to say why this would happen. Perhaps "myPlugin" changed without having its version number bumped. One thing I'd try to get rid of is "mavenLocal". Including this means that every developer's search path will be different, leading to less consistent build results. |
| Comment by Gradle Forums [ 04/Feb/14 ] |
|
We already got rid of "mavenLocal" right after this problem appeared for the very first time. |
| Comment by Gradle Forums [ 04/Feb/14 ] |
|
Strange. It's not something I've heard of before. If you find out more, let us know. |
| Comment by Gradle Forums [ 04/Feb/14 ] |
|
.. happened again (bcel was replaced by protoc on buildscript classpath). I'm wondering about this line which in fact indicates our problem: [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.DependencyGraphBuilder] Visiting configuration org.apache.bcel:bcel:2.1(default). |
| Comment by Erhard Pointl [ 13/Feb/14 ] |
|
Today this problem popped up once more, but for the very first time not within the buildscript section. But in an external dependency of a dependency configuration. 10:48:02.265 [DEBUG] [org.apache.http.headers] >> HEAD /artifactory/<repo>/c/c/a/testapps/dnw/c.c.a.testapps.dnw.dnw/0.0.1.17/c.c.a.testapps.dnw.dnw-0.0.1.17.zip HTTP/1.1 |
| Comment by Brian McDonald [ 13/Mar/15 ] |
|
I think we are seeing the same issue using 2.2.1 and it may be linked to using --refresh-dependencies Here's a simple java project with one dependency compile - Compile classpath for source set 'main'. but the classpath is /home/cruisecontrol/.gradle/caches/modules-2/files-2.1/org.apache/apache/7/6ebc3957064d9ca9d75431eb37ff40b380e64103/apache-7.pom If I delete the cache and rerun it the classpath correctly point to the slf4j-api-1.7.7.jar in the cache. We're still trying to track down the trigger, but knowing more about how the cache goes from the dependency to the file would help. Is there a metadata map being used (so it's possible to go from one group:module:version to a totally different file? If so, how can that be incorrectly updated or corrupted? |
| 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:
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. |