Hi,
This evening I tested this snapshot too. I detected huge problems with
my junit tests. After some tests run, my gradle build hangs up without
error message. I have to stop the build via ctrl+c. furthermore a java
process which is a running test I think is still listed in my process
list. Sometimes, I noticed the following error message between my
testresuls:
[ant:junit] Exception in thread "pool-1-thread-1"
java.lang.IllegalStateException: Connection is in unexpected state
AwaitIncomingEndOfStream.
[ant:junit] at
org.gradle.messaging.dispatch.DeferredConnection.dispatch(DeferredConnection.java:169)
[ant:junit] at
org.gradle.messaging.dispatch.DeferredConnection.dispatch(DeferredConnection.java:29)
[ant:junit] at
org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:194)
[ant:junit] at
org.gradle.messaging.dispatch.AsyncDispatch.access$200(AsyncDispatch.java:34)
[ant:junit] at
org.gradle.messaging.dispatch.AsyncDispatch$2.run(AsyncDispatch.java:84)
[ant:junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[ant:junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[ant:junit] at java.lang.Thread.run(Thread.java:637)
Running gradle with "-S" option doesn't offer more detailed
informations. I perceived the same problems with the gradle snapshot
taken from http://code.taglab.com/hudson/job/Gradle/386/. The
0.9-20100121145940+1100 snapshot works fine for me.
regards,
René
merscwog schrieb:
I have an alljavadoc task that attempts to aggregate information from the
sources from all subprojects into a full project javadoc task.
task alljavadoc(type: Javadoc) {}
def depTasks = []
subprojects.each
{
Project subproject ->
depTasks.add(subproject.classes)
}
alljavadoc.dependsOn depTasks
alljavadoc.doFirst()
{
Task task ->
task.project.subprojects.each
{
Project subproject ->
task.source = task.source + subproject.javadoc.source
// NOTE: All java plugin projects have "compile"
if (subproject.configurations.findByName('compile') != null)
{
subDeps = subproject.configurations.compile.getDependencies()
task.project.configurations.compile.getDependencies().addAll(subDeps)
}
// NOTE: All java war plugin projects have "providedCompile"
if (subproject.configurations.findByName('providedCompile') != null)
{
subDeps = subproject.configurations.providedCompile.getDependencies()
task.project.configurations.compile.getDependencies().addAll(subDeps)
}
}
}
This definitely works fine in 0.8, and it also worked in older 0.9 snapshots
(don't know exactly when it started failing.
The stack trace is:
at
org.gradle.api.internal.file.CompositeFileTree.getSourceCollections(CompositeFileTree.java:30)
at
org.gradle.api.internal.file.CompositeFileTree$FilteredFileTree.addSourceCollections(CompositeFileTree.java:90)
at
org.gradle.api.internal.file.CompositeFileCollection.getSourceCollections(CompositeFileCollection.java:149)
at
org.gradle.api.internal.file.CompositeFileTree.getSourceCollections(CompositeFileTree.java:30)
at
org.gradle.api.internal.file.CompositeFileTree$FilteredFileTree.addSourceCollections(CompositeFileTree.java:90)
at
org.gradle.api.internal.file.CompositeFileCollection.getSourceCollections(CompositeFileCollection.java:149)
(until StackOverflow occurs)
Obviously there is an infinite recursion happening.
There is probably a much better way to do what I've done in 0.9, but that's
what worked for me in 0.8.
I'll gladly accept suggestions on how to do the equivalent of what I've
defined in 0.9 without the failure, but since it worked in 0.8 and earlier
0.9 snapshots, I'm kind of curious as to what fundamentally changed to allow
this cycle to occur.
-Spencer
--
------------------------------------
Rene Groeschke
[email protected]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
