[GRADLE-2352] Incorrect handling of target-wildcard dependency in Ivy descriptor Created: 13/Jun/12  Updated: 11/Mar/13  Resolved: 15/Jan/13

Status: Resolved
Project: Gradle
Affects Version/s: 1.0
Fix Version/s: 1.5-rc-1

Type: Bug
Reporter: Brian Harris Assignee: Daz DeBoer
Resolution: Fixed Votes: 0


 Description   

There is a bug in the handling of ivy dependencies like "runtime->*".

org.gradle.api.internal.artifacts.ivyservice.resolveengine.DependencyGraphBuilder has this code

                        if (targetConfiguration.equals("*")) {
                            Collections.addAll(targetConfigurations, descriptor.getPublicConfigurationsNames());
                        } else {
                            targetConfigurations.add(targetConfiguration);
                        }

Consider a module X with configurations A and B, and a module Y with configuration Z, and X depends on Y with "A->*". In the above code, 'descriptor' is X's descriptor so descriptor.getPublicConfigurationsNames() will return [A,B] and it will be as if the dependency was declared as "A->A,B" which will fail to resolve. What the author probably intended was to add all of Y's configurations, just [Z], but that's not what happens here.

To workaround for now, I have changed the above code to

//                        if (targetConfiguration.equals("*")) {
//                            Collections.addAll(targetConfigurations, descriptor.getPublicConfigurationsNames());
//                        } else {
                            targetConfigurations.add(targetConfiguration);
//                        }


 Comments   
Comment by Brian Harris [ 13/Jun/12 ]

I'm concerned by this type of code existing in Gradle. It seems to be duplicating a significant amount of functionality that already exists Ivy proper which has had bugs like this weeded out over the years. I would hope you have the mindset of delegating to Ivy as much as possible, but the release notes[1] for 1.0 indicate you are heading in a different direction?

"In Gradle 1.0 we've replaced the ivy artifact cache with our own implementation, targetting performance, consistency and reliability."

Ivy dependency rules are intricate and I'd be sad to see them even partially implemented again in Gradle.

[1] http://gradle.org/docs/current/release-notes

Comment by Daz DeBoer [ 15/Jan/13 ]

Thanks to Joe Sortelli for contributing a fix with tests

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