Community
Participate
Working Groups
As per changes in bug 170831 and in http://wiki.eclipse.org/index.php/PDE_JUnit_Testing, org.eclipse.test/library.xml needs to be updated to use org.eclipse.equinox.launcher*.jar and org.eclipse.equinox.launcher.Main, as startup.jar and org.eclipse.core.launcher.Main appear to be deprecated in Eclipse I builds after 3.3M4. Or, if I'm completely off base here, please point me to the correct jar and Main class to be used to start up Eclipse for running headless JUnit tests. After much pain, I've managed to patch library.xml to prove if this'll work, by adding a new task to customTargets.xml for our JUnit tests: <target name="fixLibraryXML" description="Replace org.eclipse.test/library.xml with a version that uses equinox's launcher. Required for post-3.3M4."> <!-- get path to library.xml and launcher jar --> <property name="libraryXML" value="${workingDirectory}/eclipse/plugins/org.eclipse.test/library.xml"/> <property name="launcherJar" value="${buildDirectory}/plugins/org.eclipse.equinox.launcher.jar"/> <echo> [Equinox Hack] --- libraryXML = ${libraryXML} launcherJar = ${launcherJar} </echo> <property name="perl.cmd1" value="s#\$\{eclipse\-home\}/startup.jar#${launcherJar}#g"/> <property name="perl.cmd2" value="s#org.eclipse.core.launcher.Main#org.eclipse.equinox.launcher.Main#g"/> <tempfile property="temp.file"/> <echo message="Dynamic fix 1: perl -pe ${perl.cmd1} ${libraryXML} > ${temp.file}"/> <exec executable="perl" output="${temp.file}"> <arg value="-pe"/> <arg value="${perl.cmd1}"/> <arg value="${libraryXML}"/> </exec> <echo message="Dynamic fix 2: perl -pe ${perl.cmd2} ${temp.file} > ${libraryXML}"/> <exec executable="perl" output="${libraryXML}"> <arg value="-pe"/> <arg value="${perl.cmd2}"/> <arg value="${temp.file}"/> </exec> <delete file="${temp.file}" deleteonexit="true"/> <exec outputproperty="grepResults" executable="grep"><arg line="launcher ${libraryXML}"/></exec> <echo> [Equinox Hack] --- ${grepResults} </echo> </target> ... and I'm beginning to think that it won't: [exec] eclipse-test: [exec] [echo] Running org.eclipse.ocl.ecore.tests.AllTests [exec] [java] java.lang.NullPointerException [exec] [java] at org.eclipse.equinox.launcher.Main.takeDownSplash(Main.java:1734) [exec] [java] at org.eclipse.equinox.launcher.Main.run(Main.java:1150) [exec] [java] at org.eclipse.equinox.launcher.Main.main(Main.java:1099) Help?
I have been experimenting with using the eclipse executable instead (see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=62760).
Sonia: Sounds great. Any update / solution / advice / wiki more recent than 2004-06-01?
takeDownSplash() throwing NPE can be fixed by adding the -nosplash flag when starting eclipse. However, having done that, the next problem is: [exec] eclipse-test: [exec] [echo] Running org.eclipse.emf.ocl.tests.AllTests [exec] [java] java.lang.NullPointerException [exec] [java] at org.eclipse.equinox.launcher.Main.setExitData(Main.java:1162) [exec] [java] at org.eclipse.equinox.launcher.Main.run(Main.java:1154) [exec] [java] at org.eclipse.equinox.launcher.Main.main(Main.java:1099)
Problem comes earlier, the startup can't find the org.eclipse.osgi bundle. I suspect this comes from it being named "org.eclipse.osgi.jar". Startup looks for either "org.eclipse.osgi" (ie a folder) or something that starts with "org.eclipse.osgi_" (ie expecting a version there). This causes an exception which prevents some initialization for the JNI code causing NPEs on shutdown. Possible fixes are: 1) Keep a version on the osgi bundle: org.eclipse.osgi_3.3.0.abc 2) unzip osgi bundle into a folder name org.eclipse.osgi 3) pass the location of the bundle using -Dosgi.framework=<path/to/osgi.jar>
Created attachment 57927 [details] Patched version of library.xml This patch contributes three changes: a) create a versionless copy of plugins/org.eclipse.equinox.laucher_x.y.z.*.jar as plugins/org.eclipse.equinox.launcher.jar b) switch from startup.jar to plugins/org.eclipse.equinox.laucher.jar c) add -nosplash flag This patch has been verified by the following hacks: a) http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl.releng/builder/tests/scripts/test.xml?root=Modeling_Project&view=diff&r1=text&tr1=1.25&r2=text&tr2=1.23&diff_format=h b + c) http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl.releng/builder/tests/customTargets.xml?root=Modeling_Project&view=diff&r1=text&tr1=1.9&r2=text&tr2=1.21&diff_format=h I can provide log files showing the output of the various <echo> statements too, if desired. This fix works for MDT OCL builds. Will verify next for EMF & EMFT builds.
(In reply to comment #5) > c) add -nosplash flag This might not be necessary - I think the NPE I was getting was unrelated, but was presenting itself first in this method. Once removed, it just moved into the next place it could appear. In fact, for gui tests, you might not want to suppress this (assuming that the splash is part of some test somewhere?).
(In reply to comment #5) > Will verify next for EMF & EMFT builds. Verified for EMF, MDT OCL, MDT UML2Tools, EMFT Query and UML2 builds. Verified also that -nosplash flag is not required (using MDT OCL build only).
Just updated bug 62760 with a patch for library.xml which uses the eclipse launchers. I am testing on Windows, Linux and Mac OS X.
Anyone interested can try org.eclipse.test from the releng_test branch. It uses the eclipse executables to launch the tests. Still waiting for an opportunity to test this ourselves in our build process - taking a while with all the rebuilds this week.
(In reply to comment #9) > Anyone interested can try org.eclipse.test from the releng_test branch. It > uses the eclipse executables to launch the tests. Still waiting for an > opportunity to test this ourselves in our build process - taking a while with all the rebuilds this week. First try failed because ./eclipse isn't executable when unpacked (looks like a problem w/ the way I'm unpacking Eclipse). http://emf.torolab.ibm.com/emft/downloads/?project=query&sortBy=date&hlbuild=0#latest http://emf.torolab.ibm.com/modeling/emft/build/log-viewer.php?project=query&build=1.1.0/N200702091322/&offset=4000&step=76 Can you add this to library.xml, to make sure that the eclipse executable is always executable? <chmod file="${eclipse-home}/eclipse" perm="ugo+rx"/> Thanks!
Sure, done.
(In reply to comment #11) > Sure, done. Excellent. Did some digging and it turns out that Ant's <untar> task doesn't respect file permissions, which is why eclipse goes from 755 in the tar.gz to 644 on the filesystem. Unfortuntely, this "feature-not-a-bug" exists in both Ant 1.6.5 and 1.7.0, AFAICT. They've added some methods you can extend in order to be able to setMode() on files explicitly, but that's WAY more of a pain in the butt that this one-line 'just make sure it's executable first' fix. I'll kick another build and let you know how it goes.
Well, that fixed the permission problem, but now I'm hitting a server config issue: /home/www-data/build/emft/query/downloads/drops/1.1.0/N200702091432/testing/N200702091432/testing/target/eclipse/eclipse: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory Is there no way for the eclipse executable to start up w/o grabbing x11 or gtk libraries? We're only running core (headless) tests here, nothing w/ UI. (logfile: http://emf.torolab.ibm.com/modeling/emft/build/log-viewer.php?project=query&build=1.1.0/N200702091432/&offset=4027&step=50)
Are you running with -nosplash? I don't know if that will help though, since we are linked with the window system libraries. It would likely be a bunch of work to change things to load the window system libraries dynamically
-nosplash is specified in the library.xml in org.eclipse.test: <exec executable="${eclipse-home}/eclipse" dir="${eclipse-home}" timeout="${timeout}" logError="true" failonerror="false" output="${junit-report-output}/${classname}.txt"> <arg line="-data ${data-dir}"/> <arg line="${test-vm}"/> <arg line="-application ${application}"/> <arg line="formatter=${formatter},${test-output}"/> <arg line="-testPluginName ${plugin-name}"/> <arg line="-className ${classname}"/> <arg line="-nosplash"/> <arg line="-suppressErrors"/> <arg line="-vmargs ${vmargs} ${extraVMargs} -DPLUGIN_PATH=${plugin-path}"/> </exec>
Nick, are you running your build on build.eclipse.org? Perhaps we can ask that these librabries get installed.
(In reply to comment #16) > Nick, are you running your build on build.eclipse.org? Perhaps we can ask that > these librabries get installed. No, not yet. These libraries are on emft.eclipse.org, however. I'll spin a test there. Fingers crossed - haven't had any success running ui-test there either in the past, only core-test. Would there be value in parameterizing this somehow? Those who want to run with eclipse can use library.xml; those who want to run with <java> can use library-headless.xml? (Could also just have two main targets in the same ant script, of course. Perhaps "main-eclipse" and "main-java" (or "main-headless") ...)
Created attachment 58710 [details] patch for library.xml to create results/ folder before trying to put a file in it Progress... but still not there yet. [exec] /home/www-data/build/emft/jeteditor/downloads/drops/0.8.0/N200702092138/testing/N200702092138/testing/target/eclipse/plugins/org.eclipse.test/library.xml:61: Execute failed: java.io.FileNotFoundException: /home/www-data/build/emft/jeteditor/downloads/drops/0.8.0/N200702092138/testing/N200702092138/testing/target/eclipse/results/org.eclipse.emf.codegen.jet.editor.AllNonUISuites.txt (No such file or directory) What that really means is "Ant is trying to create a file in a directory which doesn't exist."
Patch applied, thanks.
Better, but still not good. I'm starting to agree with Thomas (see the cross-project-issues-dev mailing list) that launching with eclipse is a pain compared to launching with java. Why are we going down this road, when I had a perfectly working patch available for running w/ java? Anyway, here's the latest log: [exec] eclipse-test: [exec] [mkdir] Created dir: /home/www-data/build/emft/jeteditor/downloads/drops/0.8.0/N200702101013/testing/N200702101013/testing/target/eclipse/results [exec] [echo] Running org.eclipse.emf.codegen.jet.editor.AllNonUISuites. Results will be in /home/www-data/build/emft/jeteditor/downloads/drops/0.8.0/N2007021010 13/testing/N200702101013/testing/target/eclipse/results/org.eclipse.emf.codegen.jet.editor.AllNonUISuites.txt. [exec] [exec] Result: 1 (http://emft.eclipse.org/technology/emft/jeteditor/downloads/drops/0.8.0/N200702101013/buildlog.txt) Couldn't find any other useful debugging information at all, except this: org.eclipse.emf.codegen.jet.editor.AllNonUISuites=error1035 (http://emft.eclipse.org/technology/emft/jeteditor/downloads/drops/0.8.0/N200702101013/testing/N200702101013/testing/target/eclipse/results/testlist.txt) Can you turn on more console logging / debugging / output in the library.xml script?
Going down this path due to long-standing, bug 62760. If I understand correctly, using the eclipse launcher will also more closely approximate what occurs if you launch the application from your eclipse workspace (i.e it will use the eclipse launcher). That being said, this is still under consideration. In the meantime, I have just released some changes to the releng_test branch to do the following: -capture *.log from the eclipse/configuration directory -permit users to specify additional args to the eclipse launcher via outer "launcherArgs" Ant property setting (-consolelog for example).
(In reply to comment #21) > -capture *.log from the eclipse/configuration directory Cool... except I got no new logged information. > -permit users to specify additional args to the eclipse launcher via outer > "launcherArgs" Ant property setting (-consolelog for example). How does that get hooked in? I'm not calling library.xml explicitly - PDE's doing it for me (somehow). Best I can do with this is to perl regex a replacement like this, in order to force -consolelog: "s#\$\{launcherArgs\}#\$\{launcherArgs\} -consolelog #g" Running another build now to see if hacking -consolelog into library.xml gives me anything more useful than "Result: 1". http://emft.eclipse.org/emft/downloads/?project=jeteditor&sortBy=date&hlbuild=0#latest
I've changed the script so that -consolelog is used automatically for headless tests. I have concerns using this property for UI tests because we have had problems in the past on Windows where the console interferes with the workbench if it is not minimized.
(In reply to comment #22) Still nothing useful. Found this, but I suspect that it's irrelevant: !ENTRY org.eclipse.equinox.app 2007-02-12 19:04:41.757 !MESSAGE Product org.eclipse.sdk.ide could not be found. If you can't give me a way to better debug this failure, I'm going to revert to the v20070111 tag + my hack to use <java> with the equinox jar, instead of your version in releng_test because, frankly, using <java> works, and this doesn't. (Please excuse the snippiness: I'm getting a bit frustrated wasting time on this without useful debugging output, when my patch worked fine.) Would it be possible to have a way to choose the run method? Either two versions of library.xml or one version with different targets, as I asked in comment 17? Then I just need to know how to tell PDE which target to run, since I've no idea where the shout-out to library.xml happens. That would solve the issue of not having gtk x11 libraries available (but still having no problems otherwise running non-UI tests).
Finally, some new information! (I removed the -suppressErrors flag, and I get a whole whack of errors now.) [exec] (eclipse:22439): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed [exec] (eclipse:22439): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed [exec] (eclipse:22439): GLib-GObject-WARNING **: value "TRUE" of type `gboolean' is invalid or out of range for property `visible' of type `gboolean' [exec] (eclipse:22439): Gtk-WARNING **: Screen for GtkWindow not set; you must always set [exec] a screen for a GtkWindow before using the window (http://emft.eclipse.org/technology/emft/jeteditor/downloads/drops/0.8.0/N200702131250/testresults/consolelogs/linux.gtk_consolelog.txt) I'm just not sure what to do now. Anyone cc:'d on this bug have GTK or Pango debugging experience?
Nick, those errors indicate that the launcher tried to show a message, but failed to create a message box because it couldn't get a display. Normally, for me, this means that I haven't set the DISPLAY environment variable. If you are remoting in to the machine, you'll need to set it to the ip where you are running an x server. (ie something like "export DISPLAY=1.23.456.789:0.0")
(In reply to comment #26) > Nick, those errors indicate that the launcher tried to show a message, but > failed to create a message box because it couldn't get a display. This just underscores the fact that I can't (and don't want/need to) start up Eclipse graphically to run headless non-UI JUnits. For this use case (similar to what's discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=173742#c26), can we not create a way to invoke these tests w/ java -jar launcher.jar instead of eclipse.exe? As I can no longer test library.xml in releng_test with my current build/test servers, I have no choice but to back out and revert to the patched v20070111 version.
Support added to org.eclipse.test/library.xml to launch tests through either java or the eclipse executable in releng_test branch. The launch will default to using java unless the Ant property "useEclipseExe" is set from an outer script. I'm testing my changes now.
(In reply to comment #28) > Support added to org.eclipse.test/library.xml to launch tests through either > java or the eclipse executable in releng_test branch. The launch will default > to using java unless the Ant property "useEclipseExe" is set from an outer > script. I'm testing my changes now. Verified works for EMFT Query build. Rolling out to other projects...
Verified for MDT EODM, MDT UML2, EMF, EMFT QVT, EMFT JET/JET Editor, EMFT EODM. Thanks for adding the java-test option!
Thanks for your feedback and testing Nick! Fix released to HEAD.
(In reply to comment #31) > Thanks for your feedback and testing Nick! No problem. Please bear in mind that all the testing I've done has been with java-test, not with eclipse-test, so I can't confirm or deny that the 'run with eclipse executable' implementation works. The old-school method works great, though. ;-) > Fix released to HEAD. Thanks, I've updated my maps to use the v20070217 tag.
The option "-suppressErrors" in the eclipse launcher appears to be called differently, I looked at the source code(eclipse.c) and found quite different spelling: --launcher.suppressErrors The current state (3.3.0 M7) is that if one uses the latest testframework and the exit status is 1(failures) or 2(errors) eclipse will display the known dialog stating this, and hang till someone clicks "OK" there....
Reopening.
any news on this? The false naming of the option could seriously damage 3.3 scripting....
This will only go into 3.3 if we get enough votes for the change in bug 185732
Closing, patch in bug 185732 was released.
