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.
