build fails horribly!

[reactor]

build fails horribly!

[wilkinsona]

Sorry to hear you're having trouble with the build. We can't reproduce the problem building on a mixture of OS X and Linux. Can you give us some more info please:

• What OS are you building on?
• What's the output from java -version

[jbrisbin]

Googling this error there seems to be a Gradle Issue with building on Windows related to this and I found another traceback with a similar error caused by file locking.

http://jira.grails.org/browse/GRAILS-8586

We can't really eliminate Gradle as a build tool since even the Spring Framework itself is using it and that's the direction we've chosen to go with new development. I'm sorry you're having trouble with it.

[ldaley]

I don't think GRAILS-8586 is related.

What version of Gradle are you using?

That seems to be coming from the wrapper jar. It might be worth regenerating it with a recent Gradle version. There's something environment specific going on here as this is a code path that is hit by every build using the wrapper.

[Ed42]

Hi, I'm new to gradle but it looks as if it's using the gradle version defined in the build.
Anyway, sorry I missed this before but this was in the output of "./gradlew --debug build":

Build aborted because of an unexpected internal error. Please file an issue at: http://forums.gradle.org.

So I'll check out the gradle forum.

OS: Ubuntu 12.04.2 LTS x86_64

$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

$ cat ./gradle/wrapper/prop
#Thu May 09 13:50:28 CDT 2013
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=http://services.gradle.org/distributions/gradle-1.4-bin.zip

[ldaley]

Hi @Ed42,

Could you try checking out https://github.com/ratpack/ratpack and running ./gradlew build on that? The project is insignificant, it's just another Gradle project. If that works, then that narrows things down a little.

If that fails, then we'll have to find what it is about your environment that is causing such a deep error.

The failure actually looks to be within the JDK as it's throwing a very generic exception when trying to read the properties file.

[Ed42]

Hello @alkemist, no that doesn't work either. Fails with a different exception. It's using gradle 1.6 rather than 1.4 as in the reactor.

Here's a few lines of the nested exception:

08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: org.gradle.process.internal.ExecException: Process 'command '/opt/java/jdk1.7.0_21/bin/java'' finished with non-zero exit value 1
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:362)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:34)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.file.DefaultFileOperations.javaexec(DefaultFileOperations.java:156)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.AbstractProject.javaexec(AbstractProject.java:821)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.ProcessOperations$javaexec.call(Unknown Source)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.plugins.compass.JRubyTask.jrubyexec(JRubyTask.groovy:11)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.plugins.compass.CompassTask.super$4$jrubyexec(CompassTask.groovy)
08:18:22.603 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.plugins.compass.CompassTask.jrubyexec(CompassTask.groovy:56)
08:18:22.604 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:216)
08:18:22.604 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.BeanDynamicObject.invokeMethod(BeanDynamicObject.java:122)

I'm new to github too - is there any way I can attach a file, such as the full build output?

[ldaley]

So that's a different error. There's something peculiar about your system. I suspect it's something about the file system.

Can you please try this one: https://github.com/alkemist/gradle-test-kit

It's much simpler.

[jbrisbin]

@Ed42 If you want to attach log output, you can create a Gist [1] and put the link here in the comments.

[1] - https://gist.github.com/

[Ed42]

@alkemist, @jbrisbin the gradle-test-kit builds fine - can see it's using gradle-1.3 so I modified the build.gradle and set the gradle version to 1.6. That also builds fine.

File system is ext4, 74GB free space

[Ed42]

@alkemist @jbrisbin Looks like it's a gradle issue, at least the build problem has gone away after I did "rm -rf ~/.gradle". My guess would be that the automatic gradle install/cache mechanism got confused with previous versions somehow (I had 1.3, 1.4 and 1.6 in my ~/.gradle). Not sure how best to explain this on the gradle forum.

I did notice one consistency issue in reactor-quickstart - build.gradle has the gradle version set at 1.5, but gradle/wrapper/gradle-wrapper.properties set it to 1.4. What would you recommend as the "correct" way to specify the gradle version? My preference would be a single place, say in build.gradle.

Anyway I'm now using gradle 1.6 for both the reactor and reactor-quickstart and it's all building nicely now.

Next: how do I integrate gradle with our existing nexus repo manager --- is there a gradle equivalent of ~/.m2/settings.xml? I know, that's a gradle RTFM :-)

Thanks for your help.

[Ed42]

@alkemist @jbrisbin FYI the ratpack application still will not build with gradle 1.6. I've posted the verbose build output here

[ldaley]

@Ed42 that Ratpack issue is different. That's a specific failure with the 3rd party JRuby plugin (which is very new and experimental). It's failing because it's trying to read UTF8 files and your platform encoding is US-ASCII.

I've let the author know about this problem.

[wilkinsona]

@Ed42 Glad to hear to go to the bottom of your builds problems. Thanks for persevering, and for the pointer to the Gradle version mismatch in the quickstart repo.