[GRADLE-993] Starting Swing application with ant task may fail on OsX Created: 19/Jun/10  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: None

Type: Bug
Reporter: David Rosell Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

When I try to start a Swing application through an ant task, I get:
[ant:java] java.lang.Error: Cannot load com.apple.laf.AquaLookAndFeel

This is not totally consistent since I've created an alternative version of the application that runs. The difference between the two is that the one not working use Spring configuration (though not for the Swing part) and the other dont.

The example application can be found at:
git://github.com/daros/Progress.git

to reproduce the error:
gradle clean build SpringGuiRunner

to start without problem:
gradle clean build GuiRunner



 Comments   
Comment by David Rosell [ 19/Jun/10 ]

When I fork the Ant process everything is OK, SpringGuiRunner starts as i should.
(The reason I didn't fork was that I did want to get the error messages to find out which other dependencies I should have included - then forking is no good...)

The problem seems very similar to this over at Leiningen:
http://osdir.com/ml/clojure/2009-12/msg00874.html

Comment by Hans Dockter [ 25/Jun/10 ]

I'm not sure what the issue is. It might be related to classloaders. This is something we will work on for 1.0. In general though I would recommend to use always a forked JVM for executing Java. 0.9-preview-3 has very good support for this, including automatically capturing the output from the forked process and printing it to the console:

task springGuiRunner2(type: JavaExec) {
   main = 'se.megalit.progress.SpringGuiRunner'
   classpath = sourceSets.main.runtimeClasspath 
}

alternatively

task springGuiRunner2 << {
   javaexec {
      main = 'se.megalit.progress.SpringGuiRunner'
      classpath = sourceSets.main.runtimeClasspath 
   }
}

By default the output is printed to the console to the standard log level. You can change this behavior and for example redirect the process output to debug.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:44:09 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.