Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #411419 +++ See bug 411419 around comment 12 for more information. SWT is one of the few components that still specifies executionEnvironment in a POM. In your case, it is in a repository POM for your fragments: pom.xml - eclipse.platform.swt.binaries It seems to me these days that is just a labor-saving device for "building", but does not perform the usual "runtime checks". I realize that there is long history here, and years ago, I know you had to remove the BREEs from the fragment MANIFESTs, but I believe that is no longer the case. I realize you are busy, but ... would be nice to get completely "clean" of overrides, and get rid of this 3-year-old bug.
The more I think about it, the more I wonder if fragments are *supposed* to have their BREE listed? I seem to recall someone saying that at runtime, the "check" is to simply check the BREE of the host it gets associated to. Anyone know for sure? If true, then the way things are, is probably best.
(In reply to David Williams from comment #1) > The more I think about it, the more I wonder if fragments are *supposed* to > have their BREE listed? I seem to recall someone saying that at runtime, the > "check" is to simply check the BREE of the host it gets associated to. > > Anyone know for sure? > > If true, then the way things are, is probably best. At runtime BREEs are used at runtime by fragments. Fragments CAN have BREEs that are different from their host bundle. But I seem to recall that tycho had issues at one time if we had fragments that had different BREEs than their hosts.
(In reply to Thomas Watson from comment #2) > (In reply to David Williams from comment #1) > > The more I think about it, the more I wonder if fragments are *supposed* to > > have their BREE listed? I seem to recall someone saying that at runtime, the > > "check" is to simply check the BREE of the host it gets associated to. > > > > Anyone know for sure? > > > > If true, then the way things are, is probably best. > > At runtime BREEs are used at runtime by fragments. Fragments CAN have BREEs > that are different from their host bundle. But I seem to recall that tycho > had issues at one time if we had fragments that had different BREEs than > their hosts. Ok, thanks, Tom. I think Tycho has fixed their problem in Tycho 0.22.0. But, the "fix" might require that SWT set <resolveWithExecutionEnvironmentConstraints>false</resolveWithExecutionEnvironmentConstraints> See bug 435068. At least, if the BREEs really are different. But, I get the impression that now the BREEs could be the same at 1.7. Or, SWT team, is that not true?
BREEs for SWT fragments must have same BREE as as SWT host due to the way things are done - all sources in the host when developing but resulting classes being in fragments.
Lakshmi/Arun, should we put BREE in all manifests and drop executionEnvironment from pom or keep the status quo? I'm for the former (more obvious solution) but would like to hear others opinion before pushing for it.
I'll proceed with adding BREE to all fragments manifests and drop executionEnvironment next week if no objection by then.
New Gerrit change created: https://git.eclipse.org/r/87290
Gerrit change https://git.eclipse.org/r/87290 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=0da4de5aec072f5741c327a6b9dc87299083ac5b
A bit later than expected but still - pushed.
New Gerrit change created: https://git.eclipse.org/r/87381
Gerrit change https://git.eclipse.org/r/87381 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=85318bbd1feb5bf6d4f5984aa34f6de3625d6531
This uncovered build failure in some plugins dependent on swt but having BREE lower than 1.8 to fail compiling although resolution worked fine with exception like: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.27.0-SNAPSHOT:compile (default-compile) on project org.eclipse.ant.ui: Compilation failure: Compilation failure: [ERROR] /opt/public/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.platform/ant/org.eclipse.ant.ui/Ant Tools Support/org/eclipse/ant/internal/ui/preferences/FileSelectionDialog.java: [ERROR] /******************************************************************************* [ERROR] ^ [ERROR] The type org.eclipse.swt.widgets.Composite cannot be resolved. It is indirectly referenced from required .class files [ERROR] 1 problem (1 error) [ERROR] -> [Help 1] Reverted the commit to unbreak the build as it has to be investigated further.
(In reply to Alexander Kurtakov from comment #12) > This uncovered build failure in some plugins dependent on swt but having > BREE lower than 1.8 to fail compiling I've opened bug 509410, patch pending, to move ant to 1.8.
(In reply to Andrey Loskutov from comment #13) > (In reply to Alexander Kurtakov from comment #12) > > This uncovered build failure in some plugins dependent on swt but having > > BREE lower than 1.8 to fail compiling > > I've opened bug 509410, patch pending, to move ant to 1.8. FWIW, this would not fix the issue as in my local tests with ant.ui moved to 1.8 I experienced same issue with equinox bundles depending on swt ant there would probably be others when equinox moved.
(In reply to Andrey Loskutov from comment #13) > (In reply to Alexander Kurtakov from comment #12) > > This uncovered build failure in some plugins dependent on swt but having > > BREE lower than 1.8 to fail compiling > > I've opened bug 509410, patch pending, to move ant to 1.8. I've set the change to -2 so that it does not get merged until the reason for this bug has been found and fixed. We have other bundles with source level below 1.8 and also clients and they can all still use SWT.
In my local ant.ui compiles with Swt and swt.binaries with EE as 1.8
(In reply to Sarika Sinha from comment #16) > In my local ant.ui compiles with Swt and swt.binaries with EE as 1.8 Do you do eclipse.platform build with -Pbuild-individual-bundles or whole releng.aggregator build? I'm able to reproduce it only in the later case.
(In reply to Alexander Kurtakov from comment #17) > (In reply to Sarika Sinha from comment #16) > > In my local ant.ui compiles with Swt and swt.binaries with EE as 1.8 > > Do you do eclipse.platform build with -Pbuild-individual-bundles or whole > releng.aggregator build? I'm able to reproduce it only in the later case. Right now I have done with Eclipse IDE, Sravan tried using -Pbuild-individual-bundles but it crashed in between.
You may know this already, but Tycho 0.22 added an item to target-platform-configuration that (I think) was supposed to help with this sort of issue. See Tycho bug 435068. It was specifically meant to address bug 413116 (host/fragment BREE mismatch) which sort of sounds like the opposite of the problem you are running into now. The setting is <resolveWithExecutionEnvironmentConstraints>false</resolveWithExecutionEnvironmentConstraints> I once tried setting this for "the whole build" but there was some error then with an Equinox bundle. I do not recall what it was. See bug 453757. I just mention all this here in case anyone is motivated to experiment, or if anyone understands it better than I do.
(In reply to Dani Megert from comment #15) > I've set the change to -2 so that it does not get merged until the reason > for this bug has been found and fixed. We have other bundles with source > level below 1.8 and also clients and they can all still use SWT. Sorry, I had to push Ant's move to 1.8 due to bug 509234. Please use R4_6_maintenance for further investigations of the problem in this bug.
Is there anything left to do here?
Yeah https://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/tree/pom.xml#n89 and https://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/tree/pom.xml#n82 should not be there for this one to be done. Aka no additional hints to the build system should be needed to produce the right output.
New Gerrit change created: https://git.eclipse.org/r/164785
