On 6/06/10 12:56 AM, Steve Appling wrote:
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.
I think this change makes sense. However, I'm not 100% sure about this
stuff. I reckon if the tests all pass after the change, then it's good
to check in.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
