performance problems with trunk
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
performance problems with trunk
by Steve Appling
::
Rate this Message:
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 |
|
|
Re: performance problems with trunk
by hdockter
::
Rate this Message:
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 |
|
|
Re: performance problems with trunk
by Adam Murdoch-2
::
Rate this Message:
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 |
|
|
Re: performance problems with trunk
by Steve Appling
::
Rate this Message:
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? 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 |
|
|
Re: performance problems with trunk
by Steve Appling
::
Rate this Message:
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 |
| Free embeddable forum powered by Nabble | Forum Help |
