Il 22/04/2013 07:18, Mikolaj Izdebski ha scritto:
groovy 2.x series  (and other libraries) require gradle for build, but
with gradle there is a problem I tried to solve without success in f19
and f20 (in f18 work fine :( ).
(the same happen when rebuild gradle in non bootstrap mode)

gradle --debug jar javadoc -g
/builddir/build/BUILD/hibernate-release-4.1.7.Final/gradlehome -b
/builddir/build/BUILD/hibernate-release-4.1.7.Final/buildSrc/build.gradle
10:28:52.228 [DEBUG]
[org.gradle.logging.internal.DefaultLoggingConfigurer] Finished
configuring with level: DEBUG, configurers:
[org.gradle.logging.internal.OutputEventRenderer@14bd4d1,
org.gradle.logging.internal.slf4j.Slf4jLoggingConfigurer@180fd99,
org.gradle.logging.internal.JavaUtilLoggingConfigurer@18955ea]
10:28:52.282 [ERROR] [org.gradle.BuildExceptionReporter]
10:28:52.284 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build
aborted because of an internal error.
10:28:52.287 [ERROR] [org.gradle.BuildExceptionReporter]
10:28:52.288 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong:
10:28:52.290 [ERROR] [org.gradle.BuildExceptionReporter] Build aborted
because of an unexpected internal error. Please file an issue at:
http://forums.gradle.org
the same using -S (--full-stacktrace) parameter.
any ideas?
My ideas are:

1) Run gradle in a debugger and try to investigate what exactly is
causing the problem; "unexpected internal error" is not helping much.
already done
2) Check if the problem persists after replacing all dependencies with
binary JARs used by upstream.  If the issue is solved this way then you
can try bisection method (replace half of dependencies, then quarter and
so on, narrowing the possible cause of the problem).
i use f18 ....
3) Talk to the upstream.  They surely know more about gradle internals
and hopefully they will give you some advice how to fix the problem.

i applied a patch (#31) as suggested by A. Murdoc, gradle developer [1]
http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-printStackTrace.patch
but dont work ... probably did something wrong ...
thanks
regards


[1] Is it possible for you to temporarily add some trace to the Gradle source that you're using, as it looks like our logging is throwing away some useful details. In BuildExceptionReporter.execute(), can you add a call to failure.printStackTrace(), so that we get the full details for the failure.