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.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
