6

I'm trying to execute JUnit-tests through a headless Eclipse in our build process. The unit tests are invoked from an Ant script, with this command:

eclipsec.exe -noSplash -application org.eclipse.ant.core.antRunner -data "C:\SomeDirectory" -buildfile "C:\Path\To\tests.xml"

This works fine, unless the Ant script needs to fail for any reason (either via an explicit task because a unit test failed, or because a unit test threw an exception upstream). In either case, eclipsec raises a dialog box to report that "An error has occurred." This is accompanied by an exception. The top of the stack trace, if it is relevant, is:

java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.ant.core.AntRunner.run(AntRunner.java:513)
    at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600)

I don't really care what the Ant script or Eclipse fails for -- that's what logging is for --, but the dialog box that pops up along with it is unacceptable, because it hangs our continuous integration system while it waits for the invisible user to come click on it.

Is there any way that this dialog box can be suppressed? Is there any way I can work around this dialog box that does not require a real user to respond to it?

Additional Info:

Eclipse Version: Indigo (latest as of yesterday). Ant and JUnit internal to it.

Java Version: JDK 6.0_30 32bit

OS: Windows (7 and Server 2003)

Lii
  • 11,553
  • 8
  • 64
  • 88
Justin Aquadro
  • 2,280
  • 3
  • 21
  • 31

1 Answers1

9

If you are using subclasses of ErrorDialog, there is a static called AUTOMATED_MODE that you can set to true.

Turns out (see the comments below) that the error is coming from the wrapper program, exclipsec. Looking at the command line options here: http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html Specifying --launcher.suppressErrors on the command line will avoid this dialog (note the double dashes).

Community
  • 1
  • 1
Francis Upton IV
  • 19,322
  • 3
  • 53
  • 57
  • This looked promising, but I either do not know how to apply it, or it is not going to work in this case. I tried setting this in a JUnit test that I new would fail, but it does not prevent an eclipse error dialog. The error suppression needs to occur either at the Ant layer, or the eclipse layer, but I do not know which, or how to do it. – Justin Aquadro Dec 16 '11 at 02:50
  • When is happens, get a stack dump (kill -3 on linux) so you can see exactly which dialog is happening. It might not be a subclass of ErrorDialog (it probably is not). In that case you will need to see what's going on from the stack trace and add your own code to prevent the dialog from showing. – Francis Upton IV Dec 16 '11 at 03:33
  • Another alternative on Linux (and probably the Mac) is to use a virtual frame buffer and redirect your DISPLAY to that (xvfb). I don't know of an equivalent for Windows. – Francis Upton IV Dec 16 '11 at 03:34
  • I tried examining the process in jconsole, but among the 15 threads or so running, I couldn't infer anything. I strongly suspect the dialog is issued by eclipsec.exe itself, and I don't really know if that's Java or native code or a mix. Also even if I could redirect the output, I don't think it would help me because the modal dialog still needs to be physically closed, which isn't going to happen at 3AM. – Justin Aquadro Dec 16 '11 at 03:56
  • 1
    Can you provide a screenshot of the dialog? and Perhaps do a pastebin of the stack dump and I can have a look? – Francis Upton IV Dec 16 '11 at 04:17
  • Screenshot: http://hocuspocus.taloncrossing.com/rii/eclipsec_error.png, jstack output: http://pastebin.com/3CBrWdEs – Justin Aquadro Dec 16 '11 at 04:33
  • Also the full exception stack trace from the log: http://pastebin.com/1FckwraJ. Some of the items have minor redactions. – Justin Aquadro Dec 16 '11 at 04:34
  • Yeah, I think the problem is coming from eclipsec and something went wrong starting Eclipse. Look at the log it's pointing you to for the reason. It's something you are going to need to fix; as your tests I imagine will at least want to start Eclipse properly. – Francis Upton IV Dec 16 '11 at 07:15
  • 2
    You might want to see if there is a command line option on eclipsec that prevents it from popping up a dialog (perhaps running in some kind of headless mode). Have a look here: http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html – Francis Upton IV Dec 16 '11 at 07:17
  • I posted the full contents of the log in the second pastebin, it's not very useful. The link you posted though is different from any commandline list I've seen, and --suppressErrors is -exactly- what I was looking for. Update your answer to include that and I'll give you the points. Thanks! – Justin Aquadro Dec 16 '11 at 13:59