On Apr 23, 2010, at 6:01 PM, Adam Murdoch wrote:
>
>
> On 23/04/10 6:40 AM, Steve Appling wrote:
>> The commit on 4-19 (comment of 'GRADLE-715') is causing me some
>> difficulties. I tried various points in time in the commit history and was
>> able to narrow our problems to this one commit.
>>
>> When we are at the commit previous to this, everything works fine.
>>
>> At the current trunk head, my build fails with the following exception:
>>
>> Circular dependency between tasks. Cycle includes [task ':comm:compileJava',
>> task ':comm:jar'].
>> * Exception is:
>> org.gradle.api.CircularReferenceException: Circular dependency between
>> tasks. Cycle includes [task ':comm:compileJava', task ':comm:jar'].
>> at
>> org.gradle.execution.DefaultTaskGraphExecuter.fillDag(DefaultTaskGraphExecuter.java:116)
>> at
>> org.gradle.execution.DefaultTaskGraphExecuter.addTasks(DefaultTaskGraphExecuter.java:66)
>> at
>> org.gradle.execution.TaskNameResolvingBuildExecuter.select(TaskNameResolvingBuildExecuter.java:45)
>> at
>> org.gradle.execution.DelegatingBuildExecuter.select(DelegatingBuildExecuter.java:46)
>> at
>> org.gradle.execution.DefaultBuildExecuter.select(DefaultBuildExecuter.java:52)
>> at
>> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:172)
>> at
>> org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:115)
>> at
>> org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:82)
>> at org.gradle.launcher.Main.execute(Main.java:93)
>> at org.gradle.launcher.Main.main(Main.java:42)
>> at org.gradle.launcher.GradleMain.main(GradleMain.java:54)
>>
>>
>> Adam, I'm not quite sure how to best help debug this. Is there anything it
>> that commit that looks like it might cause this issue to you?
>>
>
> That commit was part 1 of a fix for GRADLE-715. You should now get the above
> failure if you have a cycle in your project dependencies, whereas you used to
> get a StackOverflowException. Part 2 will get rid of the above failure.
>
> The commit shouldn't have introduced new failures - just removed one problem
> so that we now bump into the next (and hopefully last) problem when you have
> project dependency cycles.
I no longer see this problem (as of last night's build). I believe it may have
been fixed by the commit on 4-26 of 'Fixed caching problem when...' - Thanks
>
>> A possible different issue - when I made a gradle build at this morning's
>> head, but didn't include that one commit (GRADLE-715), my build went
>> further, but ran into a different problem. It fails with:
>> Execution failed for task ':launcher'.
>> Cause: Could not resolve all dependencies for configuration
>> ':core:runtimeCopy'.
>> Cause: Resolved artifact
>> commons-logging:commons-logging:1.0.4;compile;commons-logging contains a
>> null value.
>>
>> While I have a configuration called ':core:runtime', I didn't explicitly
>> create one called ':core:runtimeCopy'. Are configurations copied as part of
>> the new circular dependency handling?
>
> No. It'll be something else copying the configuration. For example, some
> plugins make a copy to pass to the tasks (eg the groovy configuration).
>
>
> What does gradle -s show? What sort of repositories are you using for this
> project?
>
I am still getting this problem, but only on some build machines. A full stack
trace of the exception is:
Execution failed for task ':launcher'.
at
org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:63)
at
org.gradle.api.internal.tasks.DefaultTaskExecuter.execute(DefaultTaskExecuter.java:41)
at
org.gradle.api.internal.project.taskfactory.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:32)
at
org.gradle.api.internal.project.taskfactory.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:48)
at
org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:57)
at
org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:35)
at
org.gradle.api.internal.tasks.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:32)
at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:226)
at
org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167)
at
org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160)
at
org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78)
at
org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:161)
at
org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
at
org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:180)
at
org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:115)
at
org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:82)
at org.gradle.launcher.Main.execute(Main.java:93)
at org.gradle.launcher.Main.main(Main.java:42)
at org.gradle.launcher.GradleMain.main(GradleMain.java:54)
Caused by: org.gradle.api.artifacts.ResolveException: Could not resolve all
dependencies for configuration ':core:runtimeCopy'.
at
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.wrapException(ErrorHandlingIvyService.java:63)
at
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.access$000(ErrorHandlingIvyService.java:28)
at
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingIvyService.java:92)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:498)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:165)
at util.ConfigurationUtils.getLibsForConf(ConfigurationUtils.groovy:16)
at util.ConfigurationUtils$getLibsForConf.callStatic(Unknown Source)
at util.ConfigurationUtils.getLibs(ConfigurationUtils.groovy:24)
at
build.LauncherBuilder$_buildClassPath_closure1.doCall(LauncherBuilder.groovy:44)
at build.LauncherBuilder.buildClassPath(LauncherBuilder.groovy:38)
at build.LauncherBuilder$buildClassPath.call(Unknown Source)
at
root_gradle_fa2a33d662942f173fdb5389d4e3ece6$_run_closure3_closure60.doCall(C:\BuildAgent\work\b2ee0926717fe631\modules\buildSrc\root.gradle:435)
at
root_gradle_fa2a33d662942f173fdb5389d4e3ece6$_run_closure3.doCall(C:\BuildAgent\work\b2ee0926717fe631\modules\buildSrc\root.gradle:432)
at
org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:440)
at
org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:427)
at
org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:55)
... 18 common frames omitted
Caused by: org.gradle.api.GradleException: Resolved artifact
commons-logging:commons-logging:1.0.4;compile;commons-logging contains a null
value.
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver$ResolvedConfigurationImpl.getFiles(DefaultIvyDependencyResolver.java:130)
at
org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.getFiles(SelfResolvingDependencyResolver.java:57)
at
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingIvyService.java:90)
... 31 common frames omitted
We are using an internal nexus repo. I think this is related to the fact that
we are excluding a transitive dependency in the compile configuration. The
excluded dependency (commons-logging:1.0.4) is the one that is causing the
exception. When I change the section of DefaultIvyDependencyResolver that is
throwing the exception (line 130) to instead just not add a null to the list of
files, everything seems to work. I don't, however, think that excluding a
dependency should really be getting resolved artifacts with a null for the file
in this place, so this seems like a band-aid for a deeper problem. I think the
check on line 116 of this file is a similar band-aid.
Unfortunately, I don't understand the ivy dependency resolution enough to make
much progress on this myself.
The dependency that seems to be causing a problem includes:
compile 'commons-logging:commons-logging:1.1.1'
compile ['axis:axis:1.4', { exclude(org: 'commons-logging', module:
'commons-logging') }]
If I remove the exclude, then the 'Resolved artifact ... contains a null value'
problem goes away, but gradle tries to resolve both versions of
commons-logging. This seems to indicate some other issue. I thought that
gradle had a conflict resolution strategy of only getting the latest artifact
when resolving transitive dependencies. For some reason, that does not seem to
be working for us, which is why we added the explicit exclude in the first
place.
Sorry for the length of this - perhaps this should be broken up in to multiple
discussions, but these all seem related.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
