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?
