[GRADLE-1342] Dependency successfully resolved although it is not available from any of the listed repositories Created: 24/Jan/11 Updated: 04/Jan/13 Resolved: 22/Aug/11 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 0.9.2 |
| Fix Version/s: | 1.0-milestone-5 |
| Type: | Bug | ||
| Reporter: | Peter Niederwieser | Assignee: | Daz DeBoer |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
build.gradle: apply plugin: "java"
repositories {
flatDir name: "libs", dirs: "libs"
}
dependencies {
compile "junit:junit:4.8.2"
}
Although the libs dir is empty, JUnit is resolved successfully: :compileJava :: loading settings :: url = jar:file:/swd/app/gradle-0.9.2/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml :: resolving dependencies :: #flatdir;unspecified confs: [compile] found junit#junit;4.8.2 in clientModuleChain Turns out that the JUnit Jar from the Gradle Ivy cache is used. But this makes the build non-repeatable. |
| Comments |
| Comment by Hans Dockter [ 24/Jan/11 ] |
|
But otherwise you would need to do a often time consuming remote check for every dependency? Or are you just referring to local file system repositories? |
| Comment by Peter Niederwieser [ 24/Jan/11 ] |
|
Maybe we could only allow a dependency to be picked from the cache if it was resolved from one of the repos listed in the build file. That's also what Maven 3 is doing: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository |
| Comment by Blaine Simpson [ 03/May/11 ] |
|
I run into this problem all the time: that resolve seems to succeed even though some dependencies have not been satisfied. Basically, silent "resolve" partial failures. It looks like this is usually not accounted for by the libraries being in my environment CLASSPATH or by Gradle's classpath, because it happens for so many libraries. One tactic to make this manageable (though certainly still a major pain) is to turn off all transitivity and compare counts of dependencies vs. count of configuration files. This morning, for example, my resolve did not complain even though the dependency list contains the following, all of which really did fail to resolve because they were not present in the single local repository. By comparing dependency list to config file list, I saw what was missing. After copying them into my repository directory, the dependency list matched the config file list for subsequent Gradle runs. 'commons-httpclient:commons-httpclient:3.1@jar',
'xerces:xercesImpl:2.9.1@jar',
'org.slf4j:slf4j-api:1.6.1@jar',
'org.slf4j:slf4j-jdk14:1.6.1@jar'
|
| Comment by Peter Niederwieser [ 16/Aug/11 ] |
|
Doesn't Wharf solve this problem for us? |