Loading Profile...
EMPLOYEE
If Gradle is unable to locate a declared artifact for a module, this artifact is simply omitted from the dependencies. There is no way to tell which artifacts are missing from the declared artifacts for a module.
This bad behaviour has been reported with a number of causes:
* Artifact not present in repository
* HTTP 409 errors: http://forums.gradle.org/gradle/topic...
* Pom Relocation Elements: GRADLE-1961
We're actively working on a fix for this problem.
Help get this topic noticed by sharing it on
Twitter,
Facebook, or email.
Twitter,
Facebook, or email.
Gradle does not report missing/failed artifact downloads
-
I am also seeing gradle failing to resolve a dependency in 1 repo and not trying in any other of the defined repos. -
-
M6.
What I am seeing is a bit of an unusual situation. I had poms but not jars in a local maven repo for httpcore and httpclient (apache httpcomponents version 4.1.2)
Gradle would try to resolve it form the local repo and give up on it and not try to download th jars from other repos defined in my build.gradle.
here is my repos definition:
repositories {
mavenLocal()
maven{
credentials {
username repoUsername
password repoPassword
}
url repoUrl
name 'central'
}
mavenCentral()
}
and here are my dependencies:
dependencies {
groovy group: 'org.codehaus.groovy', name: 'groovy-all', version: '1.8.4', force: true
compile group: 'commons-cli', name: 'commons-cli', version: '1.2'
compile group: 'org.apache.ant', name: 'ant', version: '1.8.2'
compile group: 'org.apache.ant', name: 'ant-jsch', version: '1.8.2'
compile (group: 'com.syncapse.tools', name: 'aws-tools', version: '0.5'){
exclude module: 'javax.mail:mail:1.4.4'
exclude module: 'stax:stax-api:1.0.1'
}
compile group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.1.2'
compile group: 'org.apache.httpcomponents', name: 'httpmime', version: '4.1.2'
runtime group: 'com.h2database', name: 'h2', version: '1.3.158'
runtime group: 'com.jcraft', name: 'jsch', version: '0.1.44-1'
testCompile group: 'org.ccil.cowan.tagsoup', name: 'tagsoup', version: '1.2'
testCompile group: 'org.spockframework', name:'spock-core', version: '0.5-groovy-1.8'
testRuntime group: 'cglib', name:'cglib-nodep', version: '2.2.2'
testRuntime group: 'org.objenesis', name:'objenesis', version: '1.2'
}
I can send you the debug level logs grepped for both dependencies if you tell me how because I can't find a way to attach files in this system.
Cheers.
Erick. -
-
Erick: Actually what you're seeing is the expected behaviour. Repositories are considered to be self-contained: if a module is declared in a repository, then the artifacts will be resolved against the same repository.
If you want to add additional artifact locations to a maven repository use the `artifactUrls` property. See http://gradle.org/current/docs/usergu... for more details. -
-
Daz,
what do you mean by "a module is defined in a repository"?-
For a maven repository, this means that we can find the pom file for the module using the base url for the repository and the standard maven patterns.
For ivy, it means that we can find the ivy.xml using one of the defined ivyPatterns.
(There is a third possibility: ivy dependency resolvers also search for a jar file with the module name. In this case we assume a module with a single jar artifact and no dependencies. This sort of "assumed" module is only used if no real module descriptor (ivy.xml, pom.xml) can be found.) -
-
-
-
-
Ok, but how does that explain that when the jar is not found it just gets ignored and not added to the classpath?
-
-
There are 2 things here:
1) Gradle doesn't complain if a module declares an artifact, and that artifact can't be found in the _same repository the module definition was found in_. This will be fixed in Milestone7, so more builds will break rather that silently ignoring missing artifacts.
2) Gradle doesn't search for artifacts in repositories other than the one where the module definition was found. This is intended behaviour.
I think that your jars are missing because of 2), but you're not seeing errors because of 1).
I assume that the problem you're trying to solve is that the module definition for Apache HTTPComponents in Maven Central is not what you want. Often, a better way to solve this type of issue is to use a Client Module definition in your build. (see http://gradle.org/current/docs/usergu...)- view 4 more comments
-
-
-
-
-
Actually, the only action that _won't_ trigger a build failure is resolution of dependencies in the IDE. We really want the IDE project tasks to do their best to complete successfully in the face of missing dependencies. So we use the LenientConfiguration to get dependency artifacts for ide tasks. Otherwise, 'gradle eclipse' would never build your eclipse project, and you'd need to use vi to make changes until it worked :).
Any other task in gradle that uses dependency artifacts (eg compile) will fail on missing dependency artifacts.
That said, we think logging a warning about missing dependencies in the ide tasks would be useful. This is GRADLE-1945. -
-
Ah. Thanks for the clarification
I just voted for that issue.
Warnings would be fine for us. It's the silent failures that are causing issues within our teams who are new to Gradle and/or Maven. I've seen that some team members have unreasonably blamed Gradle as "buggy" even though it was their typo in a dependency definition.
Thanks. -
-
-
-
Would it make sense for gradle to try to locate the artifact on the rest of the defined repositories? Why did you guys decided not to it this way?
-
If you think this is a problem, please raise it in a new forum post so we can track it separately.