Community
Participate
Working Groups
PDE uses "TestableObject" to hook itself into a starting application/product. This is not the recommended way to write tests for pure e4, but is needed to be able to run existing 3.x tests on top of e4 and the compatibility layer.
What do you need from our end in PDE land Boris?
(In reply to comment #1) > What do you need from our end in PDE land Boris? Nothing at this point. At some later point, we can try to see if the TestableObject approach makes sense for pure e4 as well, in which case things would have to be refactored on the PDE launcher side to not depend on org.eclipse.ui (replace by package-import for references to TestableObject etc.?)
Created attachment 154700 [details] patch
SWTBot bug 391802 provides a sample JUnit test plugin that cannot be run with PDE. It seems to me that this is independant of SWTBot since the test still fails without using SWTBot. I tried to dig into the code and it seems that there is an issue having the UITestApplication to start the test thread. I mark this issue as critical hoping it will get more attention. Maybe it should be moved to PDE too.
I currently don't have time to investigate this, marking as helpwanted. It looks like it should be possible for PDE to avoid using the PlatformUITestHarness as in NonUIThreadTestApplication we can continue even if one isn't found via reflection.
Hey Curtis, It's good to know you won't be able to fix this soon. As (at least IMO) this issue is almost a blocking point for adopting e4 (ability to test a technology is one of the main adoption criteria), maybe you could get in touch with the Architecture Council to express that PDE does not support testing for Eclipse 4 applications, so they'll hopefully be able to provide you the help you want. I'd like to be able to provide a patch, but I did not succeed to get enough understanding of the code to do so.
I will bring it up at the next e4 meeting. This bug has been sitting in the e4 box for a while with no push for a fix. I don't know anyone who is an expert on the test application code. I'll cc Gunnar as he helped refactor our UI/Non-UI thread application launching. It looks like the fix is really to e4. PDE would just need to update to use the testable object from e4 rather than explicitly depend on org.eclipse.ui.
Is the Testable object still needed in e4?
(In reply to comment #8) > Is the Testable object still needed in e4? Without the testable object there is no indication of when tests should be started (resulting in no tests starting). Having PDE call workbench code via reflection is not the best way to access the test harness, but there isn't an e4 alternative currently. Currently there are several parts of the workbench/compatibility layer that should be moved to e4 (logging view/support for example). Access to the testable object is one of them. The most realistic solution is: 1) Move the test harness into e4 2) Provide a new way to access the test harness (singleton service?) 3) Update the workbench code to use the e4 test harness 4) Update PDE to use the e4 test harness
Created attachment 228594 [details] Do OSGi service registry lookup for TestableObject before creating WorkbenchTestable The attached patch adds a simple OSGi service registry lookup to org.eclipse.ui.PlatformUI.getTestableObject() before it explicitly creates a org.eclipse.ui.internal.testing.WorkbenchTestable. In case of a present E4Application, the org.eclipse.e4.ui.internal.workbench.swt.E4Testable will be found in the SR (which luckily registers itself already). This patch fixes the run issue with PDE, but also with other existing launchers/runners (SWTBot, Tycho, ...).
(In reply to comment #10) > Created attachment 228594 [details] > Do OSGi service registry lookup for TestableObject before creating > WorkbenchTestable The patch seems reasonable. > > This patch fixes the run issue with PDE, but also with other existing > launchers/runners (SWTBot, Tycho, ...). For the PDE part, would you be able to request the OSGi service and fall back on PlatformUI.getTestableObject() if it's not there? PW
About other launchers: I think you're meaning m2e-tycho when you say "m2e". If so, the patch has no effect on this laucher which is purely Maven-based. And Tycho has been able to run e4 app without any issue (since it's using it's how test executor application which does not have the same issue as PDE one). SWTBot launcher inherits from PDE launcher, so fixing this bug in PDE will fix it in SWTBot. This patch looks very good to me. I share the Paul's concern to fallback to Platform.getTestableObject() in case service is not found to ensure some backward-compatibility with old versions of Eclipse. I'd really like to this this patch part of Kepler. Thanks a lot Markus for taking care of writing it!
(In reply to comment #12) > About other launchers: > I think you're meaning m2e-tycho when you say "m2e". If so, the patch has no > effect on this laucher which is purely Maven-based. And Tycho has been able > to run e4 app without any issue (since it's using it's how test executor > application which does not have the same issue as PDE one). > SWTBot launcher inherits from PDE launcher, so fixing this bug in PDE will > fix it in SWTBot. I haven't been able to test a pure E4Application with Tycho. And I don't see how o.e.tycho.surefire.osgibooter could do this since it calls PlatformUI.getTestableObject() in AbstractUITestApplication.run(String[]). > This patch looks very good to me. I share the Paul's concern to fallback to > Platform.getTestableObject() in case service is not found to ensure some > backward-compatibility with old versions of Eclipse. It falls back to Workbench.getWorkbenchTestable() if no TO can be found in the SR.
FWIW we provide a continuous build of the eclipse.platform.releng.aggregator [1] _with_ my patch at http://download.vogella.com/kepler/I-Build/. SDK downloads for Linux, Win and Mac can be found at http://download.vogella.com/kepler/I-Build/sdk [1] https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/
Markus's patch with minor changes: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f82277e9585abbc96c22dbcd8f867092c4451e80 PDE updated to retrieve the service over calling Platform UI: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=bc6ecd8814725cb315d8a4e9a21589fbb94d3194 Give it a try and see if we have covered everyone's use case.
(In reply to comment #15) > Markus's patch with minor changes: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=f82277e9585abbc96c22dbcd8f867092c4451e80 > > PDE updated to retrieve the service over calling Platform UI: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?id=bc6ecd8814725cb315d8a4e9a21589fbb94d3194 > > Give it a try and see if we have covered everyone's use case. I think this is causing some osgi failures when org.eclipse.ui is not around. This is declared as an optional dependency by org.eclipse.pde.junit.runtime
(In reply to comment #16) > I think this is causing some osgi failures when org.eclipse.ui is not > around. This is declared as an optional dependency by > org.eclipse.pde.junit.runtime See Bug 406244. The fix there removes the dependency from the activator, but it also fixes another issue people here would have run into. If the e4 testable object was available via service, we were trying to create an ITestHarness, but ITestHarness was only available if the PlatformUI plug-in was available. This is fixed by adding an optional import-package dependency on org.eclipse.ui.testing.
