On 16 Apr 2014, at 3:48 pm, Alex Selesse <sele...@gmail.com> wrote: > Hi, > > Currently, the announce plugin does not take the _JAVA_OPTION > java.awt.headless option into consideration (i.e. > java.awt.GraphicsEnvironment.isHeadless()). > > Why does this matter? > > On OS X, if we use "export _JAVA_OPTIONS=-Djava.awt.headless=true" on a > project that uses 'build-announcements', our build fails: > > ------ > > [~/git/jxlint] $ gradle clean assemble > Picked up _JAVA_OPTIONS: -Djava.awt.headless=true > :clean > :compileJava > :processResources UP-TO-DATE > :classes > :jar > :assemble > > BUILD SUCCESSFUL > > Total time: 10.35 secs > > FAILURE: Build failed with an exception. > > * What went wrong: > Failed to notify build listener. > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or > --debug option to get more log output. > > ------ > > Running it with --debug gives the following insight: > > ------ > > 01:32:43.551 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: > javax.script.ScriptException: An error of type -10810 has occurred. > 01:32:43.552 [ERROR] [org.gradle.BuildExceptionReporter] at > apple.applescript.AppleScriptEngine.evalScript(Native Method) > 01:32:43.552 [ERROR] [org.gradle.BuildExceptionReporter] at > apple.applescript.AppleScriptEngine.eval(AppleScriptEngine.java:368) > 01:32:43.553 [ERROR] [org.gradle.BuildExceptionReporter] at > apple.applescript.AppleScriptEngine.eval(AppleScriptEngine.java:339) > 01:32:43.554 [ERROR] [org.gradle.BuildExceptionReporter] at > org.gradle.api.plugins.announce.internal.jdk6.AppleScriptBackedGrowlAnnouncer.send(AppleScriptBackedGrowlAnnouncer.groovy:49) > 0 > > ------ > > This error "-10810" happens only when we try to run AppleScript in headless > mode. I was able to reproduce this with a short Java class (I can provide > this if needed). > > My proposal is to only send local announcements if we're not in headless > mode. I could isolate the fix to the AppleScriptBackedGrowlAnnouncer class in > question, but I thought it might make more sense to respect the headless > option for ANY local announcement. Please let me know if this is reasonable.
I’d rather we didn’t short-circuit all local announcements when in headless mode, as there may still be local means available to notify the user. A better fix would be to change DefaultAnnouncerFactory to fall back to GrowlNotifyBackedAnnouncer (or possibly null) when the jvm is in headless mode and the ‘growl’ announcer is requested. > > Here's my proposed 2 line fix. Also, I'd be happy to provide tests for it, > but I'm not sure how best to do that. If you could, perhaps add an AnnouncePluginIntegrationTest, with a test case that verifies that local announcements can be used in headless mode. Take a look at BuildAnnouncementsPluginIntegrationTest for an example of a similar kind of test. Alternatively, add another test case to BuildAnnouncementsPluginIntegrationTest similar to "does not blow up when a local notification mechanism is not available” that also runs the build in headless mode. > > Let me know if this is acceptable and I'll proceed with the contribution > instructions. That’d be great. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
