Community
Participate
Working Groups
Created attachment 206704 [details] stacktrace I was using the SWTBot test launcher from the command line, and it stopped working when moving from Indigo (3.7) to Juno (4.2). I get the following error: java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) previously initiated loading for a different type with name "org/eclipse/ui/testing/TestableObject" Eclipse SDK Version: 4.1.0 Build id: I20110916-1615 SWTBot version: 2.0.5
This is blocking for me, as I still haven't found a way to launch SWTBot tests headlessly. So I had to disable the lauching of all the SWTBot unit tests for the MoDisco and EMF Facet projects.
Update: I successfully ran SWTBot on Eclipse 4.2 from the command line (on Hudson) using the Eclipse application "org.eclipse.pde.junit.runtime.nonuithreadtestapplication". See bug 364693 and the "SWTBot tests" sections of the build script: https://dev.eclipse.org/svnroot/modeling/org.eclipse.emft.facet/trunk/releng/org.eclipse.emf.facet.releng.buckminster/build-nightly.sh
Re-assigning to Platform/UI.
Fixed in http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c41ce4fb193704eadab778a9bdad8e34d83f50c5 Thank you for the report, Nicolas. The fix should be in tonight's I build (scheduled for 2200 EST). If you would like to confirm, you'll be able to get the fix from: http://download.eclipse.org/eclipse/downloads/ as the '4.2 Stream Integration Build' with a datestamp > I20120214-1310 If you notice other issues with 4.2, please file them as bugs against Platform UI.
I think we need to change our approach, as this causes problems. We now have a split package with no attributes, which can cause problems. I'm trying a quick fix to move all of org.eclipse.ui.testing into the workbench3 plugin, and re-export it from ui.workbench. PW
Brian, I've pushed an example of a full move to pwebster/bug363334. Could you check that this still works in your scenario? I'd like to get this fixed ASAP as it's in a "quantum OSGi state" ... unpredictable :-) see bug 371628 for API tool errors (which we should be able to ignore). PW
(In reply to comment #6) > Brian, I've pushed an example of a full move to pwebster/bug363334. Could you > check that this still works in your scenario? It works. I hesitated in moving the remaining classes in org.eclipse.ui.testing as they seemed E3 workbench-specific. > I'd like to get this fixed ASAP > as it's in a "quantum OSGi state" ... unpredictable :-) From reading about facade bundles, I think it should be fine (since org.eclipse.ui.workbench now has a 'Requires-Bundle: org.eclipse.e4.ui.workbench3', and then re-exports org.eclipse.ui.testing), so any bundles requesting 'Import-Package: org.eclipse.ui.testing' should (apparently) be wired to org.eclipse.ui.workbench. But avoiding the situation entirely is better.
Released migrating all of org.eclipse.ui.testing to workbench3. We'll need to keep an eye on this, of course. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c77d3af8b95ef56afe67c3b224098121d78446dc Thanx Brian, PW
