performance problems with trunk

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

performance problems with trunk

Steve Appling
I have been trying my company's build with the current main trunk, but I'm
seeing significant performance issues.  I will try to run a profiler and track
this down more, but I wanted to see if this triggered any thoughts for anyone.

With 0.8, the subset of our build that was mainly compiling java and jarring
everything up took 3:23 (min:sec).  With the current trunk, it takes 15:34.  I
added a little bit of timing to the trace and at least part of the problem is in
the logic determining if a task is up to date.
ExecutionShortCircuitTaskExecuter line 58 (repositor.getStateFor) is taking over
a minute to execute for some tasks.

These performance problems seem to be worst for subprojects with deep
dependencies.  The leaf subprojects (with no dependencies) seem to execute as
fast as before, but some of my root projects (lots of dependencies) are very
slow now. From just trying a breakpoint a few times when it is running slowly,
it seems to often be inside a chain of dependency resolvers when I think the
problem is happening.  Here is a typical stack trace:

at java.util.HashMap$HashIterator.<init>(HashMap.java:783)
at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
at java.util.HashMap.newKeyIterator(HashMap.java:840)
at java.util.HashMap$KeySet.iterator(HashMap.java:874)
at java.util.HashSet.iterator(HashSet.java:153)
at java.util.AbstractCollection.addAll(AbstractCollection.java:303)
at
org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:116)
at
org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
at
org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
at
org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
at
org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
at
org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver$ResolvedConfigurationImpl.getFiles(DefaultIvyDependencyResolver.java:99)
at
org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.getFiles(SelfResolvingDependencyResolver.java:53)
at
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingIvyService.java:90)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:513)
at
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:154)
at
org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileCollection.java:37)
at
org.gradle.api.internal.file.AbstractFileCollection.iterator(AbstractFileCollection.java:58)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$TaskInfo.<init>(DefaultTaskArtifactStateRepository.java:228)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getThisExecution(DefaultTaskArtifactStateRepository.java:91)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor(DefaultTaskArtifactStateRepository.java:48)
at
org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:58)
at
org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63)
at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36)
at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
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:174)
at
org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
at org.gradle.Main.execute(Main.java:100)
at org.gradle.Main.main(Main.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.gradle.BootstrapMain.main(BootstrapMain.java:50)


I had made some changes to add some trace messages to
ExecutionShortCircuitTaskExecuter, so line numbers in that file may be off.

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: performance problems with trunk

hans_d
Administrator

On Nov 4, 2009, at 9:33 PM, Steve Appling wrote:

> I have been trying my company's build with the current main trunk,  
> but I'm seeing significant performance issues.  I will try to run a  
> profiler and track this down more, but I wanted to see if this  
> triggered any thoughts for anyone.
>
> With 0.8, the subset of our build that was mainly compiling java and  
> jarring everything up took 3:23 (min:sec).  With the current trunk,  
> it takes 15:34.  I added a little bit of timing to the trace and at  
> least part of the problem is in the logic determining if a task is  
> up to date. ExecutionShortCircuitTaskExecuter line 58  
> (repositor.getStateFor) is taking over a minute to execute for some  
> tasks.
>
> These performance problems seem to be worst for subprojects with  
> deep dependencies.  The leaf subprojects (with no dependencies) seem  
> to execute as fast as before, but some of my root projects (lots of  
> dependencies) are very slow now. From just trying a breakpoint a few  
> times when it is running slowly, it seems to often be inside a chain  
> of dependency resolvers when I think the problem is happening.  Here  
> is a typical stack trace:

Interesting. We have changed the dependency resolution mechanism in  
0.9. I will dive into this tomorrow.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

>
> at java.util.HashMap$HashIterator.<init>(HashMap.java:783)
> at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
> at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
> at java.util.HashMap.newKeyIterator(HashMap.java:840)
> at java.util.HashMap$KeySet.iterator(HashMap.java:874)
> at java.util.HashSet.iterator(HashSet.java:153)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:303)
> at  
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts
> (DefaultResolvedDependency.java:116)
> at  
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts
> (DefaultResolvedDependency.java:119)
> at  
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts
> (DefaultResolvedDependency.java:119)
> at  
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts
> (DefaultResolvedDependency.java:119)
> at  
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts
> (DefaultResolvedDependency.java:119)
> at  
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts
> (DefaultResolvedDependency.java:119)
> at  
> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver
> $ResolvedConfigurationImpl.getFiles
> (DefaultIvyDependencyResolver.java:99)
> at  
> org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver
> $1.getFiles(SelfResolvingDependencyResolver.java:53)
> at  
> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService
> $ErrorHandlingResolvedConfiguration.getFiles
> (ErrorHandlingIvyService.java:90)
> at  
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration
> $ConfigurationFileCollection.getFiles(DefaultConfiguration.java:513)
> at  
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles
> (DefaultConfiguration.java:154)
> at org.gradle.api.internal.file.CompositeFileCollection.getFiles
> (CompositeFileCollection.java:37)
> at org.gradle.api.internal.file.AbstractFileCollection.iterator
> (AbstractFileCollection.java:58)
> at  
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository
> $TaskInfo.<init>(DefaultTaskArtifactStateRepository.java:228)
> at  
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getThisExecution
> (DefaultTaskArtifactStateRepository.java:91)
> at  
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor
> (DefaultTaskArtifactStateRepository.java:48)
> at  
> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute
> (ExecutionShortCircuitTaskExecuter.java:58)
> at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute
> (SkipTaskExecuter.java:63)
> at org.gradle.api.internal.tasks.SkipTaskExecuter.execute
> (SkipTaskExecuter.java:36)
> at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
> 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:174)
> at org.gradle.execution.DelegatingBuildExecuter.execute
> (DelegatingBuildExecuter.java:54)
> at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
> at org.gradle.Main.execute(Main.java:100)
> at org.gradle.Main.main(Main.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0
> (NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
>
>
> I had made some changes to add some trace messages to  
> ExecutionShortCircuitTaskExecuter, so line numbers in that file may  
> be off.
>
> --
> Steve Appling
> Automated Logic Research Team
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: performance problems with trunk

Adam Murdoch-2
In reply to this post by Steve Appling


Steve Appling wrote:
> I have been trying my company's build with the current main trunk, but
> I'm seeing significant performance issues.  I will try to run a
> profiler and track this down more, but I wanted to see if this
> triggered any thoughts for anyone.
>

I did fix a performance regression in trunk a day or so ago. I suspect,
however, this might be a different one.

I will try to reproduce it with the performance test project.

> With 0.8, the subset of our build that was mainly compiling java and
> jarring everything up took 3:23 (min:sec).  With the current trunk, it
> takes 15:34.  I added a little bit of timing to the trace and at least
> part of the problem is in the logic determining if a task is up to
> date. ExecutionShortCircuitTaskExecuter line 58
> (repositor.getStateFor) is taking over a minute to execute for some
> tasks.
>
> These performance problems seem to be worst for subprojects with deep
> dependencies.  The leaf subprojects (with no dependencies) seem to
> execute as fast as before, but some of my root projects (lots of
> dependencies) are very slow now.

Roughly how many is a lot of dependencies? Are they mainly project
dependencies, external dependencies?

> From just trying a breakpoint a few times when it is running slowly,
> it seems to often be inside a chain of dependency resolvers when I
> think the problem is happening.  Here is a typical stack trace:
>
> at java.util.HashMap$HashIterator.<init>(HashMap.java:783)
> at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
> at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
> at java.util.HashMap.newKeyIterator(HashMap.java:840)
> at java.util.HashMap$KeySet.iterator(HashMap.java:874)
> at java.util.HashSet.iterator(HashSet.java:153)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:303)
> at
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:116)
>
> at
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>
> at
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>
> at
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>
> at
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>
> at
> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver$ResolvedConfigurationImpl.getFiles(DefaultIvyDependencyResolver.java:99)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.getFiles(SelfResolvingDependencyResolver.java:53)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingIvyService.java:90)
>
> at
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:513)
>
> at
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:154)
>
> at
> org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileCollection.java:37)
>
> at
> org.gradle.api.internal.file.AbstractFileCollection.iterator(AbstractFileCollection.java:58)
>
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$TaskInfo.<init>(DefaultTaskArtifactStateRepository.java:228)
>
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getThisExecution(DefaultTaskArtifactStateRepository.java:91)
>
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor(DefaultTaskArtifactStateRepository.java:48)
>
> at
> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:58)
>
> at
> org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63)
>
> at
> org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36)
>
> at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
> 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:174)
>
> at
> org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
>
> at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
> at org.gradle.Main.execute(Main.java:100)
> at org.gradle.Main.main(Main.java:44)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
>
>
> I had made some changes to add some trace messages to
> ExecutionShortCircuitTaskExecuter, so line numbers in that file may be
> off.
>

--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: performance problems with trunk

Steve Appling


Adam Murdoch wrote:

>
>
> Steve Appling wrote:
>> I have been trying my company's build with the current main trunk, but
>> I'm seeing significant performance issues.  I will try to run a
>> profiler and track this down more, but I wanted to see if this
>> triggered any thoughts for anyone.
>>
>
> I did fix a performance regression in trunk a day or so ago. I suspect,
> however, this might be a different one.
>
> I will try to reproduce it with the performance test project.
>
>> With 0.8, the subset of our build that was mainly compiling java and
>> jarring everything up took 3:23 (min:sec).  With the current trunk, it
>> takes 15:34.  I added a little bit of timing to the trace and at least
>> part of the problem is in the logic determining if a task is up to
>> date. ExecutionShortCircuitTaskExecuter line 58
>> (repositor.getStateFor) is taking over a minute to execute for some
>> tasks.
>>
>> These performance problems seem to be worst for subprojects with deep
>> dependencies.  The leaf subprojects (with no dependencies) seem to
>> execute as fast as before, but some of my root projects (lots of
>> dependencies) are very slow now.
>
> Roughly how many is a lot of dependencies? Are they mainly project
> dependencies, external dependencies?
I was mainly thinking about project dependencies.  One of the projects that was
taking about 1:35 to determine if it was up to date has 12 direct compile
project dependencies.  I'm not sure how to best determine the number of
transitive projects this ends up referencing, although there are a total of
about 50 projects used in this build.  The dependencyReport for this project is
20,334 lines long.

>
>> From just trying a breakpoint a few times when it is running slowly,
>> it seems to often be inside a chain of dependency resolvers when I
>> think the problem is happening.  Here is a typical stack trace:
>

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: performance problems with trunk

Steve Appling
In reply to this post by Adam Murdoch-2
This slowdown seems to be happening while checking for changed java sources.
While I think there is a real bug here (sent Adam the snapshot), I wonder why
are we checking for changed java source files manually at all.  The ant javac
task used by compile already compares source / target files for freshness.  That
is why I added the didWork property, so you can use those results.  Checking
again to short-circuit execution of the compile task will always be slower,
won't it?

Adam Murdoch wrote:

>
>
> Steve Appling wrote:
>> I have been trying my company's build with the current main trunk, but
>> I'm seeing significant performance issues.  I will try to run a
>> profiler and track this down more, but I wanted to see if this
>> triggered any thoughts for anyone.
>>
>
> I did fix a performance regression in trunk a day or so ago. I suspect,
> however, this might be a different one.
>
> I will try to reproduce it with the performance test project.
>
>> With 0.8, the subset of our build that was mainly compiling java and
>> jarring everything up took 3:23 (min:sec).  With the current trunk, it
>> takes 15:34.  I added a little bit of timing to the trace and at least
>> part of the problem is in the logic determining if a task is up to
>> date. ExecutionShortCircuitTaskExecuter line 58
>> (repositor.getStateFor) is taking over a minute to execute for some
>> tasks.
>>
>> These performance problems seem to be worst for subprojects with deep
>> dependencies.  The leaf subprojects (with no dependencies) seem to
>> execute as fast as before, but some of my root projects (lots of
>> dependencies) are very slow now.
>
> Roughly how many is a lot of dependencies? Are they mainly project
> dependencies, external dependencies?
>
>> From just trying a breakpoint a few times when it is running slowly,
>> it seems to often be inside a chain of dependency resolvers when I
>> think the problem is happening.  Here is a typical stack trace:
>>
>> at java.util.HashMap$HashIterator.<init>(HashMap.java:783)
>> at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
>> at java.util.HashMap$KeyIterator.<init>(HashMap.java:826)
>> at java.util.HashMap.newKeyIterator(HashMap.java:840)
>> at java.util.HashMap$KeySet.iterator(HashMap.java:874)
>> at java.util.HashSet.iterator(HashSet.java:153)
>> at java.util.AbstractCollection.addAll(AbstractCollection.java:303)
>> at
>> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:116)
>>
>> at
>> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>>
>> at
>> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>>
>> at
>> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>>
>> at
>> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>>
>> at
>> org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllArtifacts(DefaultResolvedDependency.java:119)
>>
>> at
>> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver$ResolvedConfigurationImpl.getFiles(DefaultIvyDependencyResolver.java:99)
>>
>> at
>> org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.getFiles(SelfResolvingDependencyResolver.java:53)
>>
>> at
>> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingIvyService.java:90)
>>
>> at
>> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:513)
>>
>> at
>> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:154)
>>
>> at
>> org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileCollection.java:37)
>>
>> at
>> org.gradle.api.internal.file.AbstractFileCollection.iterator(AbstractFileCollection.java:58)
>>
>> at
>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$TaskInfo.<init>(DefaultTaskArtifactStateRepository.java:228)
>>
>> at
>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getThisExecution(DefaultTaskArtifactStateRepository.java:91)
>>
>> at
>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor(DefaultTaskArtifactStateRepository.java:48)
>>
>> at
>> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:58)
>>
>> at
>> org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63)
>>
>> at
>> org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36)
>>
>> at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
>> 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:174)
>>
>> at
>> org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
>>
>> at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
>> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
>> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
>> at org.gradle.Main.execute(Main.java:100)
>> at org.gradle.Main.main(Main.java:44)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
>>
>>
>> I had made some changes to add some trace messages to
>> ExecutionShortCircuitTaskExecuter, so line numbers in that file may be
>> off.
>>
>

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email