Nabble - gradle-dev

Re: Problems building the website

2009-11-09T12:57:48Z

This is all fixed now. The instructions on the wiki should work again.
We really must add a CI build for the website.

Steve Appling wrote:

> I don't seem to be able to build the website currently. I have not
> done this before, so perhaps I have some procedural problems here.
> I'm attempting to follow the instructions for building the web site at
> http://docs.codehaus.org/display/GRADLE/How+to+build+the+documentation
>
> I run (from the top level directory) "gradlew websiteDocs" and get the
> error:
>
> :docs:userguideStyleSheets UP-TO-DATE
> :docs:websiteDocs
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file
> 'C:\OpenSource\gradle\committer\subprojects\gradle-docs\docs.gradle'
> line: 289
>
> * What went wrong:
> Execution failed for task ':docs:websiteDocs'.
> Cause: No signature of method: RemoteLocations.getJavadocRemoteDir()
> is applicable for argument types: () values: []
>
>
> It appears to me that this is correct, there really is no method
> getJavadocRemoteDir on the RemoteLocations class.
>
>
>
> If I go to the website directory and run "..\gradlew build", I get:
> :build
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file 'C:\OpenSource\gradle\committer\website\build.gradle' line: 42
>
> * What went wrong:
> Execution failed for task ':build'.
> Cause: C:\OpenSource\gradle\committer\build\docs\getting-started.html
> (The system cannot find the path specified)
>
>
> This must not be my day. It's not clear to me what I am doing wrong.
> Any help would be appreciated.

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

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

http://xircles.codehaus.org/manage_email

Problems building the website

2009-11-09T12:04:35Z

I don't seem to be able to build the website currently. I have not done this
before, so perhaps I have some procedural problems here. I'm attempting to
follow the instructions for building the web site at
http://docs.codehaus.org/display/GRADLE/How+to+build+the+documentation

I run (from the top level directory) "gradlew websiteDocs" and get the error:

:docs:userguideStyleSheets UP-TO-DATE
:docs:websiteDocs

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\OpenSource\gradle\committer\subprojects\gradle-docs\docs.gradle'
line: 289

* What went wrong:
Execution failed for task ':docs:websiteDocs'.
Cause: No signature of method: RemoteLocations.getJavadocRemoteDir() is
applicable for argument types: () values: []

It appears to me that this is correct, there really is no method
getJavadocRemoteDir on the RemoteLocations class.

If I go to the website directory and run "..\gradlew build", I get:
:build

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\OpenSource\gradle\committer\website\build.gradle' line: 42

* What went wrong:
Execution failed for task ':build'.
Cause: C:\OpenSource\gradle\committer\build\docs\getting-started.html (The
system cannot find the path specified)

This must not be my day. It's not clear to me what I am doing wrong. Any help
would be appreciated.
--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Current trunk problems with retrotranslate

2009-11-09T11:50:08Z

I don't know if this is related to the recent changes to update to a new
snapshot, but I am having trouble building from source now. Gradlew assemble
ends up failing with:

:translateLibsTo14

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\OpenSource\gradle\committer\build.gradle' line: 445

* What went wrong:
Execution failed for task ':translateLibsTo14'.
Cause: Could not find method retrotranslator() for arguments [{target=1.4,
destjar=C:\OpenSource\gradle\committer\build\distributions\retroLibs\logback-core-0.9.17.jar,
smart=true, verify=false, failonwarning=false},
TranslateLibsTo14$_retroExe_closure2_closure8@1403eb7] on task ':translateLibsTo14'.

It looks like the retrotranslator call is interperted as a normal method call
and not using antbuilder. I believe that this was working fine for me a few
days ago. Does anyone else have this problem? Any ideas?

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Re: performance problems with trunk

2009-11-06T19:22:24Z

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

Re: Exception with change detection

2009-11-06T17:51:51Z

Hi,

Sorry it's taken so long. It's very frustrating. I've been trying to
update the snapshot for over a week, but I keep running into issues
(mostly of my own making, admittedly). I think I'm close now, one more
integration test to go... (again)

Steve Appling wrote:

> Adam Murdoch wrote:
>>
>>
>> Hans Dockter wrote:
>>> Hi Adam,
>>>
>>> I sometimes get the following exception with our Gradle build (after
>>> doing a -C rebuild it goes away).
>>>
>>
>> I fixed this a few days ago in trunk. I intended to update the
>> snapshot we use for gradlew to pick up this fix, but for some reason
>> the srcZip task in the new snapshot consumes vast amounts of heap
>> space, so that the product is essentially unbuildable with the new
>> snapshot (at least, on machines with limited memory). I need to hunt
>> this down before I can update the snapshot. It might take a while.
>>
>> If the problem gets too annoying, we can revert to an earlier snapshot.
>>
>>> ./gradlew check devB
>>>
>>> FAILURE: Build aborted because of an internal error.
>>>
>>> * What went wrong:
>>> Build aborted because of an unexpected internal error. Please file
>>> an issue at: www.gradle.org.
>>>
>>> * Try:
>>> Run with -d option to get additional debug info.
>>>
>>> * Exception is:
>>> java.lang.NullPointerException: null
>>> at
>>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$OutputGenerators.invalidate(DefaultTaskArtifactStateRepository.java:151)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getLastExecution(DefaultTaskArtifactStateRepository.java:102)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor(DefaultTaskArtifactStateRepository.java:49)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:51)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:174)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at
>>> org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at org.gradle.Main.execute(Main.java:100)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at org.gradle.Main.main(Main.java:44)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method) [na:1.5.0]
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> [na:1.5.0]
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> [na:1.5.0]
>>> at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
>>> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
>>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method) [na:1.5.0]
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> [na:1.5.0]
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> [na:1.5.0]
>>> at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
>>> at
>>> org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:42)
>>> [gradle-wrapper.jar:0.8-20090925104210+1000]
>>> at org.gradle.wrapper.Wrapper.execute(Wrapper.java:58)
>>> [gradle-wrapper.jar:0.8-20090925104210+1000]
>>> at org.gradle.wrapper.WrapperMain.main(WrapperMain.java:39)
>>> [gradle-wrapper.jar:0.8-20090925104210+1000]
>>>
>>> BUILD FAILED
>>>
>>> - Hans
>>>
>>> --
>>> Hans Dockter
>>> Gradle Project Manager
>>> http://www.gradle.org
>>>
>>
> I keep getting this too. It is making it a pain to build. Do you
> think you could look into the zip problem.
>
> Thanks
>

Re: Exception with change detection

2009-11-06T08:06:24Z

Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> Hi Adam,
>>
>> I sometimes get the following exception with our Gradle build (after
>> doing a -C rebuild it goes away).
>>
>
> I fixed this a few days ago in trunk. I intended to update the snapshot
> we use for gradlew to pick up this fix, but for some reason the srcZip
> task in the new snapshot consumes vast amounts of heap space, so that
> the product is essentially unbuildable with the new snapshot (at least,
> on machines with limited memory). I need to hunt this down before I can
> update the snapshot. It might take a while.
>
> If the problem gets too annoying, we can revert to an earlier snapshot.
>
>> ./gradlew check devB
>>
>> FAILURE: Build aborted because of an internal error.
>>
>> * What went wrong:
>> Build aborted because of an unexpected internal error. Please file an
>> issue at: www.gradle.org.
>>
>> * Try:
>> Run with -d option to get additional debug info.
>>
>> * Exception is:
>> java.lang.NullPointerException: null
>> at
>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$OutputGenerators.invalidate(DefaultTaskArtifactStateRepository.java:151)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getLastExecution(DefaultTaskArtifactStateRepository.java:102)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor(DefaultTaskArtifactStateRepository.java:49)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:51)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:174)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at
>> org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at org.gradle.Main.execute(Main.java:100)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at org.gradle.Main.main(Main.java:44)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [na:1.5.0]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> [na:1.5.0]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> [na:1.5.0]
>> at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
>> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
>> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [na:1.5.0]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> [na:1.5.0]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> [na:1.5.0]
>> at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
>> at
>> org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:42)
>> [gradle-wrapper.jar:0.8-20090925104210+1000]
>> at org.gradle.wrapper.Wrapper.execute(Wrapper.java:58)
>> [gradle-wrapper.jar:0.8-20090925104210+1000]
>> at org.gradle.wrapper.WrapperMain.main(WrapperMain.java:39)
>> [gradle-wrapper.jar:0.8-20090925104210+1000]
>>
>> BUILD FAILED
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project Manager
>> http://www.gradle.org
>>
>

I keep getting this too. It is making it a pain to build. Do you think you
could look into the zip problem.

Thanks

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Re: performance problems with trunk

2009-11-04T13:54:27Z

Adam Murdoch wrote:

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

Re: performance problems with trunk

2009-11-04T13:36:42Z

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.
>

Re: performance problems with trunk

2009-11-04T13:29:28Z

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

performance problems with trunk

2009-11-04T12:33:03Z

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

Unexpected behaviour ?

2009-11-01T03:32:54Z

Using Gradle Wrapper 0.9-20091020112559+1100, Gant builds and all its
tests pass.

Using Gradle as at 2009-11-01 11:30+00:00 compilations of the code and
the tests are fine but only about 25% of the tests are picked up and
most of them fail with a java.lang.NoClassDefFoundError:
groovy/lang/GroovyObject

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Status of nightly docs build

2009-10-30T07:02:36Z

Our nightly docs build, that uploads the newest javadoc, groovydoc and
user's guide to our website, was not working properly recently. For
two reasons:

- There was a bug in the build script and the wrong remote directory
was used. This is fixed.
- FTP'ing from our CI machine works sometimes but most of the times
not. We don't know why yet. Yegor from Teamcity is having a fresh look
at the problem.

I have uploaded a fresh version of the latest docs. So the links are
working again.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: CopySpec.remapTarget is gone!

2009-10-29T06:59:12Z

On Wed, Oct 28, 2009 at 9:31 PM, Adam Murdoch <a@...> wrote:

<snip>

This method might look something like:

eachFile { FileCopyDetails details ->

if (not a special file) {
return
}

perform phase one renaming
perform phase two renaming

if (resultName is not valid) {
details.exclude()
}
else {
details.setPath(resultName)
}
}

FileCopyDetails would extend FileVisitDetails and add methods to allow you to:
- exclude the file from the result
- set the destination name or the path for the file
- set the filter to use when reading or writing to the file

That sounds like a good solution to me. Especially since we are needing to filter as well in our current use-case. We are doing that by having two different froms in the copySpec. Both has the same remapTarget closure, but one excludes files that we need to filter and the other includes files we need to filter and sets up a filter. Like this:

copy.from(fromDir) {
    filteredFiles.each { exclude it }
    remapTarget remapClosure
}
copy.from(fromDir) {
    filteredFiles.each { include it }
    remapTarget remapClosure
    filter(ReplaceTokens, tokens:replacedTokens)
}

This is because filtering binary files often corrupts them, so we only wanted to filter some of the files. We didn't like this way is it requires the copy to make two passes through the from directory, however. Your idea will allow us to do this in one pass, and it's nice and explicit. I like it. I guess this is a case of "state your problem, not your solution". Sorry about that.

--
John Murph
Automated Logic Research Team

Re: CopySpec.remapTarget is gone!

2009-10-28T18:31:22Z

John Murph wrote:

> I'm not sure that separating include/exclude rules from the remapping
> is a good idea. On the surface it sure sounds reasonable, but I think
> it would make our use case much uglier. Our remap code is sorta like:
>
> remapTarget { File inputFile ->
> if (not a special file)
> return inputFile
>
> perform phase one renaming // fairly complicated
> perform phase two renaming // also complicated
>
> if (resultName is not valid) // did phase one and phase two result
> in the desired format?
> return null
> else
> return resultName
> }
>
> The point is that phase one and phase two renaming are not simple
> replaceAll kinds of functions. This means that if we were to split up
> these concepts we would has an include/exclude closure that performed
> the logic and then checks if the resultName is valid. Then we need a
> mapTo closure that performed the logic and returned the result (with
> an assert failure if the result name is not valid?). Now, we could
> pull this common stuff into a method, but it just seems an overly
> complicated way of getting the desired behavior. It also seems like
> it would affect performance when processing over 30,000 files.
>

This is a reasonable use case. I'm not sold on the solution, however.
My concern is this:

There are currently 3 primitive operations you can apply to a CopySpec:
- selecting: decide whether a given file should be excluded from the result
- mapping: determine the destination path for a given file
- filtering: filter the content of a given file when copying it

Each of these operations is logically independent. But sometimes, as in
your case, a given piece of build logic means that more than 1 of these
operations need to be applied to a given file.

The problem with combining selecting and mapping in the mapTo() method
is that it only solves the problem for the particular combination of
operations that you happen to need. It doesn't solve it for builds that
need to map and filter or select and filter. This becomes more of a
problem as we add more operations, such as
- signing: determine the signature for a given file
- permissions: determine the owner, group and permissions for a given file

So, merging the primitive operations into discrete combinations is not a
general solution, nor a particularly backwards compatible one.

I think instead, we want a single 'do everything' method which you can
pass a closure (or Action) which can apply any of the primitive
operations to the given file, however it wants. The existing selecting,
mapping and filtering method would remain simply as convenience methods.

This method might look something like:

eachFile { FileCopyDetails details ->
if (not a special file) {
return
}

perform phase one renaming
perform phase two renaming

if (resultName is not valid) {
details.exclude()
}
else {
details.setPath(resultName)
}
}

FileCopyDetails would extend FileVisitDetails and add methods to allow
you to:
- exclude the file from the result
- set the destination name or the path for the file
- set the filter to use when reading or writing to the file

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

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

http://xircles.codehaus.org/manage_email

Re: CopySpec.remapTarget is gone!

2009-10-28T14:31:11Z

I'm not sure that separating include/exclude rules from the remapping is a good idea. On the surface it sure sounds reasonable, but I think it would make our use case much uglier. Our remap code is sorta like:

remapTarget { File inputFile ->
if (not a special file)
     return inputFile

perform phase one renaming // fairly complicated
perform phase two renaming // also complicated

if (resultName is not valid) // did phase one and phase two result in the desired format?
     return null
else
     return resultName
}

The point is that phase one and phase two renaming are not simple replaceAll kinds of functions. This means that if we were to split up these concepts we would has an include/exclude closure that performed the logic and then checks if the resultName is valid. Then we need a mapTo closure that performed the logic and returned the result (with an assert failure if the result name is not valid?). Now, we could pull this common stuff into a method, but it just seems an overly complicated way of getting the desired behavior. It also seems like it would affect performance when processing over 30,000 files.

--
John Murph
Automated Logic Research Team

Re: CopySpec.remapTarget is gone!

2009-10-27T17:17:27Z

Steve Appling wrote:

> CopySpec.remapTarget is gone and we were actually using it. The
> replacement rename method that takes a closure isn't equivalent. It
> only takes a string file name as a parameter (and as the return), so I
> can't do things like flatten a directory tree during a copy. The
> previous remapTarget method (admittedly a poor name) took and returned
> File objects so you could tell the directory the source files were in
> (and control the directory of the target). We were also using the
> fact that you could previously return a null to not copy the file. I
> would like these abilities back in some form.
>

They will be back. I moved remapTarget() out of the way to make it
easier to change the archive tasks to use CopySpec. Once that is done, I
am planning on adding remapping back in some form.

I'd like to separate how you specify whether a file should be included
in the result and how you specify the target path for a file.

To include and exclude files, we have
PatternFilterable.include(Spec<FileTreeElement>) and include(Closure),
plus the equivalent exclude() methods. FileTreeElement provides a bunch
of meta info about the source file. So you can do something like:

include { FileTreeElement e ->
e.file.text.contains("environment=${targetEnvironment}") }

To specify the target path, we would add a general mapTo() method. You
would provide a mapping from FileTreeElement to the destination relative
path for the file. The path would be interpreted relative to the root of
the destination (whether that is a directory or a zip file or whatever).
Something like:

mapTo { FileTreeElement e ->
return e.path.replaceAll('-TARGET.zip', "-${version}.zip")
}

We might also replace what is currently rename() with a mapPath()
method, where you provide a mapping from String relative path to String
relative path:

mapName { it.replaceAll('-TARGET.zip', "-${version}.zip") }

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

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

http://xircles.codehaus.org/manage_email

CopySpec.remapTarget is gone!

2009-10-27T14:07:34Z

CopySpec.remapTarget is gone and we were actually using it. The replacement
rename method that takes a closure isn't equivalent. It only takes a string
file name as a parameter (and as the return), so I can't do things like flatten
a directory tree during a copy. The previous remapTarget method (admittedly a
poor name) took and returned File objects so you could tell the directory the
source files were in (and control the directory of the target). We were also
using the fact that you could previously return a null to not copy the file. I
would like these abilities back in some form.

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Re: version.properties

2009-10-27T08:42:51Z

On Tue, 2009-10-27 at 11:08 -0400, John Murph wrote:
> Hans,

> Also, I suggest you get it from the IMPLEMENTATION
> VERSION section of the manifest and not by parsing the
> jar file name.
>
> Because you think this is more reliable?

> I think it is better form that parsing the file name, because of the
> reliability issue. It also happens to enforce that the version
> information is put in the jars manifest, which is nice. But mostly,
> because that's how IDEA determines the version of Gradle and
> consistency is good.

Gant originally parsed the jar name to get the version number but this
proved seriously unreliable in situations such as Debian and Ubuntu
where the version number is removed for packaging.

Also perverse people might just change the version number embedded in
the file name just for the hell of it.

So I switched to ensuring the version was put into the jar metadata, aka
manifest, and getting it from there. Much more reliable.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: version.properties

2009-10-27T08:08:52Z

Hans,

Also, I suggest you get it from the IMPLEMENTATION VERSION section of the manifest and not by parsing the jar file name.

Because you think this is more reliable?

I think it is better form that parsing the file name, because of the reliability issue. It also happens to enforce that the version information is put in the jars manifest, which is nice. But mostly, because that's how IDEA determines the version of Gradle and consistency is good.

--
John Murph
Automated Logic Research Team

Re: version.properties

2009-10-26T14:26:53Z

Hi John,

On Oct 26, 2009, at 5:35 PM, John Murph wrote:

> That seems reasonable to me. The version.properties file seems
> redundant, so let's do away with it. From which jar would you read
> the version (gradle-core)?

I think so.

> Also, I suggest you get it from the IMPLEMENTATION VERSION section
> of the manifest and not by parsing the jar file name.

Because you think this is more reliable?

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Is this an internal Gradle problem

2009-10-26T14:25:07Z

On Oct 24, 2009, at 8:52 AM, Russel Winder wrote:

> On Sat, 2009-10-24 at 07:34 +1100, Adam Murdoch wrote:
>> You probably need to do a clean and then build Gradle (at least
>> until we
>> have incremental compilation).
>
> This is a fresh compile after a clean.
>
> Actually it would be very helpful if someone could branch the Bazaar
> branch and try it to see if the same result obtains.
>
> http://www.russel.org.uk/Bazaar/ADS

Unfortunately I could not check this out with bazaar 1.10. I have the
Mac 2.0.1 Bazaar bundle but bzr --version still gives a 1.10.

Could you send a src zip?

- Hans

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

>
> I just got the same result running Gradle against a branch new
> branch :-(
>
>> Russel Winder wrote:
>>> I haven't build ADS using Gradle for a while so I just tried.
>>> Clearly
>>> there is something wrong, either a breaking change that I haven't
>>> tracked in the build,gradle or a problem in Gradle. I suspect the
>>> former but the message doesn't give me much to go on :-(
>>>
>>> :compileJava
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Build file '/home/users/russel/Repositories/Bazaar/Masters/
>>> ADS/build.gradle'
>>>
>>> * What went wrong:
>>> Execution failed for task ':compileJava'.
>>> Cause: org.gradle.api.tasks.util.FileSet cannot be cast to
>>> groovy.lang.GroovyObject
>>>
>>> * Try:
>>> Run with -S option to get the full (very verbose) stacktrace.
>>>
>>> * Exception is:
>>> org.gradle.api.GradleScriptException: Build file '/home/
>>> users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'
>>> Execution failed for task ':compileJava'.
>>> at
>>> org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions
>>> (DefaultTaskExecuter.java:64) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.tasks.DefaultTaskExecuter.execute
>>> (DefaultTaskExecuter.java:43) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute
>>> (ExecutionShortCircuitTaskExecuter.java:56) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute
>>> (SkipTaskExecuter.java:63) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.api.internal.tasks.SkipTaskExecuter.execute
>>> (SkipTaskExecuter.java:36) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.api.internal.AbstractTask.execute
>>> (AbstractTask.java:215) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at
>>> org.gradle.execution.DefaultTaskGraphExecuter.executeTask
>>> (DefaultTaskGraphExecuter.java:167) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.execution.DefaultTaskGraphExecuter.doExecute
>>> (DefaultTaskGraphExecuter.java:160) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.execution.DefaultTaskGraphExecuter.execute
>>> (DefaultTaskGraphExecuter.java:78) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.execution.TaskNameResolvingBuildExecuter.execute
>>> (TaskNameResolvingBuildExecuter.java:174) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.execution.DelegatingBuildExecuter.execute
>>> (DelegatingBuildExecuter.java:54) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.execution.DelegatingBuildExecuter.execute
>>> (DelegatingBuildExecuter.java:54) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.GradleLauncher.doBuildStages
>>> (GradleLauncher.java:193) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:
>>> 128) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
>>> [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.Main.execute(Main.java:100) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.Main.main(Main.java:44) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
>>> [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> Caused by: java.lang.ClassCastException:
>>> org.gradle.api.tasks.util.FileSet cannot be cast to
>>> groovy.lang.GroovyObject
>>> at
>>> org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder
>>> $_addToAntBuilder_closure1.doCall
>>> (AntFileCollectionMatchingTaskBuilder.groovy:15) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder.addToAntBuilder
>>> (AntFileCollectionMatchingTaskBuilder.groovy:14) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.file.AbstractFileCollection.addAsMatchingTask
>>> (AbstractFileCollection.java:90) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.file.AbstractFileCollection.addToAntBuilder
>>> (AbstractFileCollection.java:85) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.api.tasks.compile.AntJavac
>>> $_execute_closure2.doCall(AntJavac.groovy:67) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.api.tasks.compile.AntJavac
>>> $_execute_closure2.doCall(AntJavac.groovy) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod
>>> (BasicAntBuilder.java:74) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at org.gradle.api.internal.project.DefaultAntBuilder.super
>>> $3$invokeMethod(DefaultAntBuilder.groovy) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod
>>> (DefaultAntBuilder.groovy:37) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at org.gradle.api.tasks.compile.AntJavac.execute
>>> (AntJavac.groovy:66) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at org.gradle.api.tasks.compile.Compile.compile
>>> (Compile.java:57) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at org.gradle.api.DefaultTask.invokeMethod
>>> (DefaultTask.groovy) [gradle-core-0.9-20091023090404+0100.jar:
>>> 0.9-20091023090404+0100]
>>> at org.gradle.util.ReflectionUtil.invoke
>>> (ReflectionUtil.groovy:23) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.project.AnnotationProcessingTaskFactory
>>> $2.execute(AnnotationProcessingTaskFactory.java:125) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.project.AnnotationProcessingTaskFactory
>>> $2.execute(AnnotationProcessingTaskFactory.java:123) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> at
>>> org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions
>>> (DefaultTaskExecuter.java:56) [gradle-
>>> core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
>>> ... 17 common frames omitted
>>>
>>> BUILD FAILED
>>>
>>> Total time: 7.838 secs
>>>
>>>
>>
> --
> Russel.
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> Dr Russel Winder Partner
> xmpp: russel@...
> Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
> London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

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

http://xircles.codehaus.org/manage_email

Re: Exception with change detection

2009-10-26T13:14:44Z

Hans Dockter wrote:
> Hi Adam,
>
> I sometimes get the following exception with our Gradle build (after
> doing a -C rebuild it goes away).
>

I fixed this a few days ago in trunk. I intended to update the snapshot
we use for gradlew to pick up this fix, but for some reason the srcZip
task in the new snapshot consumes vast amounts of heap space, so that
the product is essentially unbuildable with the new snapshot (at least,
on machines with limited memory). I need to hunt this down before I can
update the snapshot. It might take a while.

If the problem gets too annoying, we can revert to an earlier snapshot.

> ./gradlew check devB
>
> FAILURE: Build aborted because of an internal error.
>
> * What went wrong:
> Build aborted because of an unexpected internal error. Please file an
> issue at: www.gradle.org.
>
> * Try:
> Run with -d option to get additional debug info.
>
> * Exception is:
> java.lang.NullPointerException: null
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$OutputGenerators.invalidate(DefaultTaskArtifactStateRepository.java:151)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getLastExecution(DefaultTaskArtifactStateRepository.java:102)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor(DefaultTaskArtifactStateRepository.java:49)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:51)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:174)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at
> org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at org.gradle.Main.execute(Main.java:100)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at org.gradle.Main.main(Main.java:44)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [na:1.5.0]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [na:1.5.0]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [na:1.5.0]
> at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
> at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
> [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [na:1.5.0]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [na:1.5.0]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [na:1.5.0]
> at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
> at
> org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:42)
> [gradle-wrapper.jar:0.8-20090925104210+1000]
> at org.gradle.wrapper.Wrapper.execute(Wrapper.java:58)
> [gradle-wrapper.jar:0.8-20090925104210+1000]
> at org.gradle.wrapper.WrapperMain.main(WrapperMain.java:39)
> [gradle-wrapper.jar:0.8-20090925104210+1000]
>
> BUILD FAILED
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

Re: version.properties

2009-10-26T09:35:53Z

That seems reasonable to me. The version.properties file seems redundant, so let's do away with it. From which jar would you read the version (gradle-core)? Also, I suggest you get it from the IMPLEMENTATION VERSION section of the manifest and not by parsing the jar file name.

--
John Murph
Automated Logic Research Team

Exception with change detection

2009-10-26T03:35:49Z

Hi Adam,

I sometimes get the following exception with our Gradle build (after
doing a -C rebuild it goes away).

./gradlew check devB

FAILURE: Build aborted because of an internal error.

* What went wrong:
Build aborted because of an unexpected internal error. Please file an
issue at: www.gradle.org.

* Try:
Run with -d option to get additional debug info.

* Exception is:
java.lang.NullPointerException: null
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository
$OutputGenerators.invalidate(DefaultTaskArtifactStateRepository.java:
151) [gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getLastExecution
(DefaultTaskArtifactStateRepository.java:102) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository.getStateFor
(DefaultTaskArtifactStateRepository.java:49) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at
org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute
(ExecutionShortCircuitTaskExecuter.java:51) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute
(SkipTaskExecuter.java:63) [gradle-core-0.9-20091020112559+1100.jar:
0.9-20091020112559+1100]
at org.gradle.api.internal.tasks.SkipTaskExecuter.execute
(SkipTaskExecuter.java:36) [gradle-core-0.9-20091020112559+1100.jar:
0.9-20091020112559+1100]
at org.gradle.api.internal.AbstractTask.execute
(AbstractTask.java:215) [gradle-core-0.9-20091020112559+1100.jar:
0.9-20091020112559+1100]
at org.gradle.execution.DefaultTaskGraphExecuter.executeTask
(DefaultTaskGraphExecuter.java:167) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.execution.DefaultTaskGraphExecuter.doExecute
(DefaultTaskGraphExecuter.java:160) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.execution.DefaultTaskGraphExecuter.execute
(DefaultTaskGraphExecuter.java:78) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.execution.TaskNameResolvingBuildExecuter.execute
(TaskNameResolvingBuildExecuter.java:174) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.execution.DelegatingBuildExecuter.execute
(DelegatingBuildExecuter.java:54) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.GradleLauncher.doBuildStages
(GradleLauncher.java:193) [gradle-core-0.9-20091020112559+1100.jar:
0.9-20091020112559+1100]
at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128)
[gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.GradleLauncher.run(GradleLauncher.java:98)
[gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.Main.execute(Main.java:100) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at org.gradle.Main.main(Main.java:44) [gradle-
core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) [na:1.5.0]
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39) [na:1.5.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) [na:1.5.0]
at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
at org.gradle.BootstrapMain.main(BootstrapMain.java:50)
[gradle-core-0.9-20091020112559+1100.jar:0.9-20091020112559+1100]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) [na:1.5.0]
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39) [na:1.5.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) [na:1.5.0]
at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0]
at org.gradle.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:42) [gradle-wrapper.jar:
0.8-20090925104210+1000]
at org.gradle.wrapper.Wrapper.execute(Wrapper.java:58)
[gradle-wrapper.jar:0.8-20090925104210+1000]
at org.gradle.wrapper.WrapperMain.main(WrapperMain.java:39)
[gradle-wrapper.jar:0.8-20090925104210+1000]

BUILD FAILED

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Incremental compilation [ was Is this an internal Gradle problem ]

2009-10-25T09:30:44Z

Hi Russel,

On Oct 24, 2009, at 9:01 AM, Russel Winder wrote:

> On Sat, 2009-10-24 at 07:34 +1100, Adam Murdoch wrote:
>> You probably need to do a clean and then build Gradle (at least
>> until we
>> have incremental compilation).
>
> It just struck me that you say Gradle doesn't yet have incremental
> compilation. I had thought that the whole point of the DAG was that
> each and every file was checked separately for needing to be compiled
> and that all import dependencies were also checked to ensure that
> transitive dependencies on changed files were transmitted through. If
> this is not yet the case then it is likely that many people have been
> working under a big misapprehension.

I don't think that many people have this misunderstanding. The DAG
contains task. The Java files are all compiled by one task. In this
case it is the job of the compile task to be smart.

>
> One of the biggest problems with Java compilation is that Javac is
> basically useless at handling these issues and Ant and Maven (and
> Gant)
> don't do anything extra. This is where SCons wins hugely since it
> handles all this very, very carefully. This has to be Gradle's USP --
> "no more always building from clean as with Ant and Maven".
>
> Can I suggest that this be the blocking issue for 0.9?

We offer incremental compilation (via the Ant depend task under the
hood). At the moment you have to switch it on explicitly.

<compileTaskName>.options.useDepends = true

We might use this as the default for 0.9.

After 0.9 we are thinking about providing an own incremental compile
implementation which would also catch some cases which are not covered
by the Ant depend task. This would only work with Java 6. For Java 5
users we would still delegate to Ant depend.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Making Gradle output even less verbose

2009-10-24T00:37:57Z

> On Fri, 2009-10-23 at 22:16 +0200, Hans Dockter wrote:
>> With the new incremental functionality our users will have now a lot
>> of output like:
>>
>> test UP-TO-DATE
>>
>> I think it would be cool to have no output for this at all (as a
>> default). Usually your only interested in what needs to be done and to
>> see what is work in progress.
>
> Actually I like seeing this.

Me too. I like to be informed about the progress.
But if I can configure this display (if I can easily say I want to see
this output or not), than the default settings are not so important to
me.

--
Tomek

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

http://xircles.codehaus.org/manage_email

Re: Incremental compilation [ was Is this an internal Gradle problem ]

2009-10-24T00:01:29Z

On Sat, 2009-10-24 at 07:34 +1100, Adam Murdoch wrote:
> You probably need to do a clean and then build Gradle (at least until we
> have incremental compilation).

It just struck me that you say Gradle doesn't yet have incremental
compilation. I had thought that the whole point of the DAG was that
each and every file was checked separately for needing to be compiled
and that all import dependencies were also checked to ensure that
transitive dependencies on changed files were transmitted through. If
this is not yet the case then it is likely that many people have been
working under a big misapprehension.

One of the biggest problems with Java compilation is that Javac is
basically useless at handling these issues and Ant and Maven (and Gant)
don't do anything extra. This is where SCons wins hugely since it
handles all this very, very carefully. This has to be Gradle's USP --
"no more always building from clean as with Ant and Maven".

Can I suggest that this be the blocking issue for 0.9?

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Making Gradle output even less verbose

2009-10-23T23:55:33Z

On Fri, 2009-10-23 at 22:16 +0200, Hans Dockter wrote:
> With the new incremental functionality our users will have now a lot
> of output like:
>
> test UP-TO-DATE
>
> I think it would be cool to have no output for this at all (as a
> default). Usually your only interested in what needs to be done and to
> see what is work in progress.

Actually I like seeing this.

> Related to this are tasks that are just aggregators. It would be nice
> to exclude them in the output if the tasks they aggregate don't do
> anything (e.g. check, classes).

On the other hand ensuring that the sequence of tasks output matches the
users model of what is going on is better.

> The third catagory are task like the Copy task (e.g.
> processResources). We might be able to restructure them in a way that
> we could some in advance check whether something needs to be done or
> not (e.g. from input exists or not).
>
> I think all that would reduce noise and would make the real issues/
> warning more prominent.

The problem is that if task tags are not output that relate to the trace
of tasks and dependencies then the user model of activity is violated.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Is this an internal Gradle problem

2009-10-23T23:52:03Z

On Sat, 2009-10-24 at 07:34 +1100, Adam Murdoch wrote:
> You probably need to do a clean and then build Gradle (at least until we
> have incremental compilation).

This is a fresh compile after a clean.

Actually it would be very helpful if someone could branch the Bazaar
branch and try it to see if the same result obtains.

http://www.russel.org.uk/Bazaar/ADS

I just got the same result running Gradle against a branch new
branch :-(

> Russel Winder wrote:
> > I haven't build ADS using Gradle for a while so I just tried. Clearly
> > there is something wrong, either a breaking change that I haven't
> > tracked in the build,gradle or a problem in Gradle. I suspect the
> > former but the message doesn't give me much to go on :-(
> >
> > :compileJava
> >
> > FAILURE: Build failed with an exception.
> >
> > * Where:
> > Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'
> >
> > * What went wrong:
> > Execution failed for task ':compileJava'.
> > Cause: org.gradle.api.tasks.util.FileSet cannot be cast to groovy.lang.GroovyObject
> >
> > * Try:
> > Run with -S option to get the full (very verbose) stacktrace.
> >
> > * Exception is:
> > org.gradle.api.GradleScriptException: Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'
> > Execution failed for task ':compileJava'.
> > at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:64) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.tasks.DefaultTaskExecuter.execute(DefaultTaskExecuter.java:43) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:56) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:174) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.GradleLauncher.run(GradleLauncher.java:98) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.Main.execute(Main.java:100) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.Main.main(Main.java:44) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.BootstrapMain.main(BootstrapMain.java:50) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > Caused by: java.lang.ClassCastException: org.gradle.api.tasks.util.FileSet cannot be cast to groovy.lang.GroovyObject
> > at org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder$_addToAntBuilder_closure1.doCall(AntFileCollectionMatchingTaskBuilder.groovy:15) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder.addToAntBuilder(AntFileCollectionMatchingTaskBuilder.groovy:14) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.file.AbstractFileCollection.addAsMatchingTask(AbstractFileCollection.java:90) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.file.AbstractFileCollection.addToAntBuilder(AbstractFileCollection.java:85) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.tasks.compile.AntJavac$_execute_closure2.doCall(AntJavac.groovy:67) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.tasks.compile.AntJavac$_execute_closure2.doCall(AntJavac.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:74) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.tasks.compile.AntJavac.execute(AntJavac.groovy:66) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.tasks.compile.Compile.compile(Compile.java:57) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:56) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> > ... 17 common frames omitted
> >
> > BUILD FAILED
> >
> > Total time: 7.838 secs
> >
> >
>

Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Making Gradle output even less verbose

2009-10-23T13:45:35Z

Hans Dockter wrote:
> With the new incremental functionality our users will have now a lot
> of output like:
>
> test UP-TO-DATE
>
> I think it would be cool to have no output for this at all (as a
> default). Usually your only interested in what needs to be done and to
> see what is work in progress.

Sounds reasonable. We'd have to try this and see how it works.

For consistency:
* We should have no output for disabled tasks.
* We should show output for any buildSrc tasks that are executed.

We should also combine this with some logging at info level which
explains why a task did no work.

>
> Related to this are tasks that are just aggregators. It would be nice
> to exclude them in the output if the tasks they aggregate don't do
> anything (e.g. check, classes).
>

My plan is to treat an aggregator task as up-to-date if all its
dependencies are up-to-date. Then, whatever we do for up-to-date tasks
will be applied to these as well.

> The third catagory are task like the Copy task (e.g.
> processResources). We might be able to restructure them in a way that
> we could some in advance check whether something needs to be done or
> not (e.g. from input exists or not).
>

Copy and the archive tasks don't have the full set of input and output
files registered yet. They will soon, and they will work exactly the
same as all the other tasks.

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

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

http://xircles.codehaus.org/manage_email

Re: Is this an internal Gradle problem

2009-10-23T13:34:08Z

You probably need to do a clean and then build Gradle (at least until we
have incremental compilation).

Russel Winder wrote:

> I haven't build ADS using Gradle for a while so I just tried. Clearly
> there is something wrong, either a breaking change that I haven't
> tracked in the build,gradle or a problem in Gradle. I suspect the
> former but the message doesn't give me much to go on :-(
>
> :compileJava
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'
>
> * What went wrong:
> Execution failed for task ':compileJava'.
> Cause: org.gradle.api.tasks.util.FileSet cannot be cast to groovy.lang.GroovyObject
>
> * Try:
> Run with -S option to get the full (very verbose) stacktrace.
>
> * Exception is:
> org.gradle.api.GradleScriptException: Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'
> Execution failed for task ':compileJava'.
> at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:64) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.tasks.DefaultTaskExecuter.execute(DefaultTaskExecuter.java:43) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:56) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:174) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.GradleLauncher.run(GradleLauncher.java:98) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.Main.execute(Main.java:100) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.Main.main(Main.java:44) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.BootstrapMain.main(BootstrapMain.java:50) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> Caused by: java.lang.ClassCastException: org.gradle.api.tasks.util.FileSet cannot be cast to groovy.lang.GroovyObject
> at org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder$_addToAntBuilder_closure1.doCall(AntFileCollectionMatchingTaskBuilder.groovy:15) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder.addToAntBuilder(AntFileCollectionMatchingTaskBuilder.groovy:14) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.file.AbstractFileCollection.addAsMatchingTask(AbstractFileCollection.java:90) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.file.AbstractFileCollection.addToAntBuilder(AbstractFileCollection.java:85) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.tasks.compile.AntJavac$_execute_closure2.doCall(AntJavac.groovy:67) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.tasks.compile.AntJavac$_execute_closure2.doCall(AntJavac.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:74) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.tasks.compile.AntJavac.execute(AntJavac.groovy:66) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.tasks.compile.Compile.compile(Compile.java:57) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:56) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
> ... 17 common frames omitted
>
> BUILD FAILED
>
> Total time: 7.838 secs
>
>

version.properties

2009-10-23T13:28:38Z

I think the place where we store the version.properties is not the
place where it should live. Right now it lives in gradle-core. But in
fact the version is the version of the distribution not of the
library. That means that we would need to check for the changed input
properties of all our archives to see whether we need a new version
file. That would be possible. But I think a simpler approach would
work as well. I think we should get rid of the version.properties file
all together. Instead the GradleVersion class could read the version
from one of the gradle libraries in GRADLE_HOME/lib. We would have to
give up of the buildTime attribute in gradle -v. But I don't think
this attribute is relevant. Either you have a released version or you
have a version with a timestamp. The latter gives you all the
information you need for a snapshot.

In a snapshot build we would then always use a new timestamped version
(as we do now). But it would only affect the naming of the archives
not the content. With Adam's planned optimization for output file
changes only (which in the case of an archive just renames the
archive), our build could then make full use of the incremental build
optimization. In fact the output file changes optimization is
necessary to make all that work. Otherwise our (unchanged) archives
are not in sync with the current timestamped version.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Making Gradle output even less verbose

2009-10-23T13:16:29Z

With the new incremental functionality our users will have now a lot
of output like:

test UP-TO-DATE

I think it would be cool to have no output for this at all (as a
default). Usually your only interested in what needs to be done and to
see what is work in progress.

Related to this are tasks that are just aggregators. It would be nice
to exclude them in the output if the tasks they aggregate don't do
anything (e.g. check, classes).

The third catagory are task like the Copy task (e.g.
processResources). We might be able to restructure them in a way that
we could some in advance check whether something needs to be done or
not (e.g. from input exists or not).

I think all that would reduce noise and would make the real issues/
warning more prominent.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: build from sources - latest snapshot - dists or distLibs ?

2009-10-23T12:28:56Z

> I think it should be assemble, as dists changed to assemble with gradle 0.7
> => 0.8.
> I posted a patch for this on the mailing lists on the 30.9.2009, seems it
> never made it to the repo.
So let us make it more "official" :)
http://jira.codehaus.org/browse/GRADLE-717

please comment on this JIRA issue if you know how it should be done properly

--
Tomek

>
> Thomas
>
>
> Tomek Kaczanowski wrote:
>>
>> John, Adam - thanks.
>>
>> but my point is that:
>> http://gradle.org/build.html is telling lies
>> and
>> build.gradle has default tasks that are no longer valid.
>>
>> both things are misleading and do not help to start contributing to
>> gradle.
>>
>> --
>> Tomek
>>
>>
>>
>> 2009/10/22 Adam Murdoch <a@...>:
>>
>>>
>>> Some tasks you could use, depending on what you want to do: 'assemble',
>>> 'binZip' or 'install'
>>>
>>> Tomek Kaczanowski wrote:
>>>
>>>>
>>>> hi all,
>>>>
>>>> I pulled the latest gradle src from git (and then downloaded latest
>>>> src from TeamCity to check it once again, and then from
>>>> http://snapshots.dist.codehaus.org/gradle/ to make sure I'm not
>>>> dreaming ;). I followed the http://gradle.org/build.html and run
>>>>
>>>> ./gradlew clean dists
>>>>
>>>> but failed each time with:
>>>> FAILURE: Could not determine which tasks to execute.
>>>>
>>>> * What went wrong:
>>>> Task 'dists' not found in root project 'gradle'.
>>>>
>>>> * Try:
>>>> Run with -t to get a list of available tasks.
>>>>
>>>> BUILD FAILED
>>>>
>>>> ./gradlew -t gives me plenty of tasks, but not "dists"
>>>>
>>>> distLibs seems like a proper one to me. But I'm confused - build.gradle
>>>> says:
>>>> defaultTasks "clean", "dists"
>>>>
>>>> ?
>>>> --
>>>> Tomek
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Adam Murdoch
>>> Gradle Developer
>>> http://www.gradle.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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

Is this an internal Gradle problem

2009-10-23T11:38:20Z

I haven't build ADS using Gradle for a while so I just tried. Clearly
there is something wrong, either a breaking change that I haven't
tracked in the build,gradle or a problem in Gradle. I suspect the
former but the message doesn't give me much to go on :-(

:compileJava

FAILURE: Build failed with an exception.

* Where:
Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'

* What went wrong:
Execution failed for task ':compileJava'.
Cause: org.gradle.api.tasks.util.FileSet cannot be cast to groovy.lang.GroovyObject

* Try:
Run with -S option to get the full (very verbose) stacktrace.

* Exception is:
org.gradle.api.GradleScriptException: Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'
Execution failed for task ':compileJava'.
at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:64) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.tasks.DefaultTaskExecuter.execute(DefaultTaskExecuter.java:43) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.project.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:56) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:63) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:36) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:215) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:174) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:193) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.GradleLauncher.run(GradleLauncher.java:98) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.Main.execute(Main.java:100) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.Main.main(Main.java:44) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.BootstrapMain.main(BootstrapMain.java:50) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
Caused by: java.lang.ClassCastException: org.gradle.api.tasks.util.FileSet cannot be cast to groovy.lang.GroovyObject
at org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder$_addToAntBuilder_closure1.doCall(AntFileCollectionMatchingTaskBuilder.groovy:15) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.file.AntFileCollectionMatchingTaskBuilder.addToAntBuilder(AntFileCollectionMatchingTaskBuilder.groovy:14) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.file.AbstractFileCollection.addAsMatchingTask(AbstractFileCollection.java:90) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.file.AbstractFileCollection.addToAntBuilder(AbstractFileCollection.java:85) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.tasks.compile.AntJavac$_execute_closure2.doCall(AntJavac.groovy:67) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.tasks.compile.AntJavac$_execute_closure2.doCall(AntJavac.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:74) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.tasks.compile.AntJavac.execute(AntJavac.groovy:66) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.tasks.compile.Compile.compile(Compile.java:57) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:56) [gradle-core-0.9-20091023090404+0100.jar:0.9-20091023090404+0100]
... 17 common frames omitted

BUILD FAILED

Total time: 7.838 secs

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment