On Jun 4, 2010, at 10:34 PM, Steve Appling wrote: > > On Jun 4, 2010, at 2:56 AM, Adam Murdoch wrote: > >> >> >> On 4/06/10 5:33 AM, Steve Appling wrote: >>> >>> >>> On May 31, 2010, at 7:09 PM, Adam Murdoch wrote: >>> >>>> >>>> >>>> On 29/05/10 3:57 AM, Steve Appling wrote: >>>>> We would really like to resolve the issues related to circular >>>>> dependencies (GRADLE-914 in particular) sometime soon. I know this is >>>>> marked for 0.9, but so are 91 other issues. Is this something that >>>>> anyone is planning on addressing in the short term (within the next >>>>> couple of weeks)? If not, does anyone understand the underlying problem >>>>> enough to point me in the right direction? >>>>> >>>> >>>> I know of 2 problems. There may be more, but this is as far as I got: >>>> >>>> 1. The compile configuration is now transitive by default (for good or >>>> bad). So, using a runtime dependency to break the cycle isn't going to >>>> work. This is easily fixed by configuring the compile configuration to be >>>> non-transitive. But, this does highlight some awkwardness in the >>>> dependency dsl, where the only options are to include the jar on its own >>>> or the entire transitive closure of everything the jar might need (even >>>> though it doesn't for the purposes of compiling a dependent project). I >>>> think we need something more flexible here, so we can provide a better >>>> default behaviour. >>>> >>>> 2. The DefaultProjectDependency.getBuildDependencies() implementation >>>> doesn't consider whether the configuration it belongs to is transitive or >>>> not. And so, it always drags in the tasks to build the runtime >>>> configuration of the target project, even though only the jar may be >>>> required. This is the actual bug. >>>> >>>> I was going to try to fix this for 0.9. But there's plenty of other stuff >>>> to fix, so if you want to have a look at this, feel free to do so. >>> >>> The particular problem that I was running into seems to be different from >>> the ones you were describing. I think I have a fix for this, but wanted to >>> check this with you (Adam) before committing anything. I'm over my head >>> here, so my solution might not be appropriate. >>> >>> Simplified version of my situation: >>> >>> We have a functionalTestRuntime configuration that extends runtime and is >>> used to specify dependencies needed to run the functional tests for a >>> project. >>> Project A has a functionalTestRuntime project dependency on Project B. >>> Project B has a compile project dependency on Project A. >>> >>> Before executing the functionalTest task on Project A, the isUpToDate check >>> tries to resolve the functionalTestRuntime configuration. >>> Both of the projects will have the following configurations: >>> archives, default, compile, runtime, testCompile, testRuntime, >>> functionalTestRuntime >>> >>> When the DefaultIvyService is used to resolve Project A's >>> functionalTestRuntime configuration, it creates a ModuleDescriptor to >>> describe the project (DefaultIvyService:134). This ModuleDescriptor only >>> includes the functionalTestRuntime configuration and its >>> superconfigurations in the ModuleDescriptor (which doesn't include the >>> default configuration). When the compile project dependency from Project B >>> -> Project A is being resolved, it tries to find the default configuration >>> of Project A. Project A really does have a default configuration, but Ivy >>> uses the ModuleDescriptor created that was created above, which doesn't >>> have it. The result is an exception like: >>> >>> org.gradle.api.artifacts.LocationAwareResolveException: >>> Could not resolve all dependencies for configuration >>> ':ProjectA:functionalTestRuntime': >>> - unresolved dependency: >>> com.controlj.green#ProjectA;1.0-SNAPSHOT: configuration not found in >>> com.controlj.green#ProjectA;1.0-SNAPSHOT: 'default'. It was required >>> from com.controlj.green#ProjectB;1.0-SNAPSHOT compile >>> >>> >>> >>> Changing >>> DefaultIvyService line 134 to include all configurations instead of >>> just the ones from the current configuration's hierarchy seems to fix >>> this particular problem. The change would be to replace >>> "configuation.getHierarchy()" with "configuration.getAll()". Does this >>> seem appropriate? >>> >>> >>> >> >> This looks like a good solution. >> > > This is causing the SamplesExcludesAndClassifiersIntegrationTest to fail. It > causes configurations.otherConf.resolve() to return "service-1.0-jdk15" > instead of "service-1.0-jdk14". I'm trying to follow the Ivy code resolving > this, but it's not yet clear to me why it picks up the classifier from the > wrong configuration. >
I think I've tracked this down too, but again would like advice. In AbstractDependencyDescriptorFactoryInternal.findExistingDescriptor, it only compares the ModuleRevisionIds of the dependencies. The ModuleRevisionId only has the group, name, and version. In particular, it does not include information about the artifact (like the classifier). It seems like findExistingDescriptor should pull out the DependencyArtifactDescriptors from the DependencyDescriptor and compare them as well. I think this part of the code was originally written by Hans, but didn't know if either Hans or Adam had an opinion about this.
