[GRADLE-3118] Defined dependency artifact not used when resolving a module with no metadata file Created: 02/Jul/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.1-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Daz DeBoer
Resolution: Fixed Votes: 0

Known Issue Of:
2.0

 Description   

This is a regression in dependency resolution in Gradle 2.0. The issue occurs when there is no ivy.xml for a module, and the dependency declares and artifact where the artifact name does not match the module name.

When trying to locate the module metadata, Gradle 2.0 will search first for the ivy.xml file for the module, then the default 'jar' artifact. Instead Gradle should be searching for the declared artifact if the ivy.xml file is not found.

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

Hi,

I can't observe a difference using this script and 2.0 and 1.12. Would you mind providing some instructions we can follow to observe the difference?

Comment by Gradle Forums [ 02/Jul/14 ]

Ok...here is a basic HelloWorld gradle project with one dependencies....

apply plugin: 'java'

sourceCompatibility = 1.5
version = '1.0'

def artifactory_contextUrl = hasProperty('artifactory_contextUrl') ?
artifactory_contextUrl :
defaultArtifactoryContextUrl

repositories {
maven {
url "${artifactory_contextUrl}/public"
}
ivy {
url "${artifactory_contextUrl}/prerelease"
layout "pattern", {
artifact "[organisation]/[module]/[revision]/[type]/[artifact][revision]([classifier]).[ext]"
}
}
ivy {
url "${artifactory_contextUrl}/external"
layout "pattern", {
artifact "[organisation]/[module]/[revision]/[type]/[artifact][revision]([classifier]).[ext]"
}
}
ivy {
url "${artifactory_contextUrl}/repo1-cache"
layout "pattern", {
artifact "[organisation]/[module]/[revision]/[type]/[artifact][revision]([classifier]).[ext]"
artifact "[organisation]/[module]/[revision]/[artifact][revision]([classifier]).[ext]"
m2compatible = true
}
}
}

dependencies {
compile (group: 'com.example', name: 'mytools', version: '3535') {
// explicitly adding the dependency artifact
// artifact name is different than module name
artifact {
name = 'Mytools'
extension = 'jar'
type = 'jar'
}
}
}

Here is the build output using gradle version 1.12

C:\Users\jmessmer\IdeaProjects\gradleDependencyHandlerTest>which gradle
C:\Program Files\gradle\gradle-1.12\bin\gradle

C:\Users\jmessmer\IdeaProjects\gradleDependencyHandlerTest>gradle build
:compileJava
Download http://myArtifactoryURL.com:8081/artifactory/prerelease/com.example/mytools/3535/jar/Mytools-3535.jar
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build UP-TO-DATE

BUILD SUCCESSFUL

Total time: 3.052 secs

Here is the build output when I try do use gradle version 2.0:

C:\Users\jmessmer\IdeaProjects\gradleDependencyHandlerTest>which gradle
C:\Program Files\gradle\gradle-2.0\bin\gradle

C:\Users\jmessmer\IdeaProjects\gradleDependencyHandlerTest>gradle build
:compileJava

FAILURE: Build failed with an exception.

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 7.425 secs

C:\Users\jmessmer\IdeaProjects\gradleDependencyHandlerTest>

As you can see, my artifact has a different nomenclature than the module name....I am not sure if I need to do something different and how when I go to gradle 2.0

Thanks,
Jay

Comment by Daz DeBoer [ 04/Jul/14 ]

I can confirm this is a regression in dependency resolution in Gradle 2.0. The issue occurs when there is no ivy.xml for a module, and the artifact name does not match the module name.

The tricky thing is that it looks like this has been already fixed in master, even though there's been no corresponding bug report. Can you try a recent nightly build (http://gradle.org/nightly) and see if it fixes your problem?

Comment by Andreas Nyberg [ 05/Jul/14 ]

I spent most of yesterday battling with this problem: an ivy module declared a dependency on another ivy module with an explicit artifact, but the resolver didn't look for the named artifact but only one with the name of the module.

  1. I would investigate this in conjunction with GRADLE-2329 that has plagued us for years now.
  2. This should be part of a larger discussion about handling Ivy repositories.
    • Apache/Ant/Ivy settings allows control over whether to proceed without an Ivy descriptor. This matters in cases with several repositories searched; proceeding without the descriptor may mean picking up artifacts using a repository without the ivy descriptor and not searching a subsequent repository that has a matching Ivy descriptor.
    • Apache/Ant/Ivy setting allows matching a repository to a group/module rather than blindly searching in sequence.
    • Rather than trying to cover all these "settings" through configuration, would it not make more sense to offer an "algorithmic" Ivy resolver since all this is easy to express in code, and Gradle "config" IS code? "If coordinates match x/y/z, look for ivy descriptor here than there, if not found try these artifact locations/give up this resolver."
Comment by Daz DeBoer [ 05/Jul/14 ]

Thanks Andreas. The main thing we want to do now is address the regression in 2.0. My belief is that it has now been fixed in master. Any chance that you can try a nightly build (http://gradle.org/nightly) and confirm if this is the case.

Regarding your other suggestions, I would recommend taking this discussion to the Gradle developers list (http://www.gradle.org/development).

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