Community
Participate
Working Groups
We must add tests to ensure that the e4 layer stays clean of SWT dependencies. See https://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg06849.html If swt is not on the bundle classpath smth as simple as: @Test(expected = ClassNotFoundException.class) public void noSWT() { Class.forName("org.eclipse.swt.widgets.Widget"); } should verify it's not added by mistake.
See Bug 378811 for what can happens without these tests.
I think this is not the correct test for the issue. It only tests if the *test bundle* has no dependencies to the SWT, but it does not test if the *actual* e4 bundle class loader can load the SWT related class. If I'm not completely wrong, solution would be to change the test that for *each* affected e4 bundle we get the classloader of one from bundle classes and asks those classloaders to load "org.eclipse.swt.widgets.Widget" class => and this should fail.
I think the test needs to be modified to look like this: @Test(expected = ClassNotFoundException.class) public void noSWT() { Class.forName("org.eclipse.swt.widgets.Widget", true, E4Workbench.class.getClassLoader()); }
(In reply to Andrey Loskutov from comment #2) > I think this is not the correct test for the issue. It only tests if the > *test bundle* has no dependencies to the SWT, but it does not test if the > *actual* e4 bundle class loader can load the SWT related class. > Correct. > If I'm not completely wrong, solution would be to change the test that for > *each* affected e4 bundle we get the classloader of one from bundle classes > and asks those classloaders to load "org.eclipse.swt.widgets.Widget" class > => and this should fail. Correct we need to use the classloader of the bundle instead.
The following bundles in platform need this check: - org.eclipse.e4.core.commands - org.eclipse.e4.emf.xpath - org.eclipse.e4.ui.css.core (not 100% sure) - org.eclipse.e4.ui.di - org.eclipse.e4.ui.model.workbench - org.eclipse.e4.ui.services - org.eclipse.e4.ui.workbench
Even better check would be protected Bundle getBundle(String id) { return ... } @Test public void noSWT_commands() { assertTrue( noSWT("org.eclipse.e4.core.commands") ); assertTrue( noSWT("...") ); .... } public boolean noSWT(String id) { try { getBundle(id).loadClass("org.eclipse.swt.widgets.Widget"); } catch( ClassNotFoundException e ) { return true; } return false; }
(In reply to Thomas Schindl from comment #6) > Even better check would be > > protected Bundle getBundle(String id) { > return ... > } > > @Test > public void noSWT_commands() { > assertTrue( noSWT("org.eclipse.e4.core.commands") ); > assertTrue( noSWT("...") ); > .... > } > > public boolean noSWT(String id) { > try { > getBundle(id).loadClass("org.eclipse.swt.widgets.Widget"); > } catch( ClassNotFoundException e ) { > return true; > } > return false; > } As much as it will be easier to write all checks in one place, I find it hard when tests for one bundle are in another bundle tests - e.g. tests that swt is not present in e4.core.commands being in org.eclipse.e4.emf.xpath.test or vice-versa. Such a test I wouldn't even call a duplication but it's better to be in the respective test bundle so people working on the given bundle notice the issue immediately and not only after the N-build which is monitored by very few people that reopen bugs and etc.
These tests related to classpath all sound great and may have prevented the current problem. But, if I am not mistaken, the actual "root problem" occurred during a build, where the p2 content metadata "said" there was a dependency. Through the "magic of p2", there are other ways to specify dependencies in p2 metadata. While "being on the classpath" (via manifest.mf) is the most common way, I just wanted to point this out, in case anyone was concerned. I do not know of any easy test for that I think you would have to "walk" the content.xml file.
Mass move to 4.6 RC1. We might push out more to 4.7.
Moving out of Neon. If you still want to fix something during RC3 then please retarget and make sure you follow the rules: https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_6.php#FixPassAfterRC2
Currently no cycles to implement this, please reopen if you are planning to provide a fix.
