Community
Participate
Working Groups
On Windows 10, 64 bit, switching the Eclipse QVTo Tycho build backwards and forwards between http://download.eclipse.org/eclipse/updates/4.9/R-4.9-201809060745/ http://download.eclipse.org/eclipse/updates/4.10-I-builds/I20180929-1800/ causes the [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.2.0:compile (default-compile) on project org.eclipse.m2m.qvt.oml.emf.util.ui: Compilation failure: Compilation failure: [ERROR] E:\GIT\org.eclipse.qvto\plugins\org.eclipse.m2m.qvt.oml.emf.util.ui\src\org\eclipse\m2m\internal\qvt\oml\emf\util\ui\EmfUtilUiImages.java:[1] [ERROR] /******************************************************************************* [ERROR] ^ [ERROR] The type org.eclipse.swt.graphics.Image cannot be resolved. It is indirectly referenced from required .class files [ERROR] E:\GIT\org.eclipse.qvto\plugins\org.eclipse.m2m.qvt.oml.emf.util.ui\src\org\eclipse\m2m\internal\qvt\oml\emf\util\ui\EmfUtilUiImages.java:[15] [ERROR] import org.eclipse.swt.graphics.Image; [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... to come and go. Building interactively on an I20180929-1800 installation does not reproduce the problem. ?? Has the retraction of win32 support confused the Tycho 1.2.0 classpath ??
Adding the usual .class not visible workaround makes no difference. Import-Package: org.eclipse.swt.graphics, org.eclipse.swt.layout Adding to the Tycho target platform: <unit id="org.eclipse.swt.win32.win32.x86_64" version="0.0.0"/> gives: [ERROR] Cannot resolve target definition: [ERROR] Problems resolving provisioning plan.: [ERROR] org.eclipse.swt.win32.win32.x86_64 3.108.100.v20181004-1733 cannot be installed in this environment because its filter is not applicable. which seems potentially significant but not anything that I understand. Naively I suspect that lazy Windows coders have always tested "win32" and it is only now that "win32" has vanished that latent bugs have become serious.
Raising to critical (almost blocker) since building on 4.10 is not possible.
Back to normal. Very simple workaround/fix found. My target definition file contains the longstanding environments declarations <environments> <environment> <os>win32</os> <ws>win32</ws> <arch>x86</arch> </environment> <environment> <os>win32</os> <ws>win32</ws> <arch>x86_64</arch> </environment> ... </environments> If I remove the no longer supported win32 x64 the Tycho compilations succeed as before. Clearly claiming that my build works on win32 x64 is actually wrong and so removing the claim is a fix. However surely something should have told me that that one of platforms lacked a required fragment? ?? Move to Tycho ??
Thats the problem with the fragment approach, that from an OSGi point of view the fragment is optional, but from SWT point of view its mandatory.
(In reply to Christoph Läubrich from comment #4) > Thats the problem with the fragment approach, that from an OSGi point of > view the fragment is optional, but from SWT point of view its mandatory. Surely not? A fragment might be blamed for a failure to provide something that should be available. This bug is a side effect of a failure to find an unnecessary irrelevant declaration causing a real failure in a healthy context.
(In reply to Ed Willink from comment #3) > If I remove the no longer supported win32 x64 the Tycho compilations succeed > as before. Correction. Remove win32 x86. Keep win32 x86_64.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Comment #4 accepts that there is a problem. No furether comment therefore not CLOSED WONTFIX.
@Ed the problem is that recent Eclipse/SWT do no longer support x86 (neither on Windows nor on linux/mac) anymore, so the build failure you see here is cause by requesting an invalid platform that cannot be resolved. So as long as you won't suggest to put back x86 support into SWT I fear there is nothing much SWT (or tycho) could do here...
I'm certainly not suggesting resurrecting x86. I would just like to see a better diagnostic. It seems to me a warning that x86 is unknown would do. As it is or rather was, I spent considerable amount of time debugging an obscure corollary that 'diagnosed' the need to delete a gratuitous legacy architecture.
If I remember right this was some similar in Bug 361901 the problem is that there is no standard way for a bundle to reacquire at least one fragment so it might not be possible to give better diagnostics.
