Community
Participate
Working Groups
Created attachment 232669 [details] list of 38 bundles that specify custom <executionEnvironment> I'll attach full list, with my "annotations" for each, but I'd estimate at least half of the cases should not need to specify a custom <executionEnvironment> ... and half of that half would be better fixed by specifying a BREE in the MANIFEST.MF file (mostly examples and tests) and then using "standard" pom.xml. Only one case, I think, in this list, would result in unintended byte codes being produced. org.eclipse.equinox.transforms.hook But, in general, I think we should strive to having simple, "standard" POMs, and not have extra things in them that are not needed (or, better fixed without changing standard POM). Of the other half, which I think are correct, given what we have today ... I think there are several questions: If the <executionEnvironment> is being used to "force" the highest level of compilation of BREEs listed, instead of the lowest BREE in Manifest.mf, then I wonder if those lower BREEs are really still needed in the Manifest.mf? Some of the issues, seen in early prototype MIGHT have been caused by "pom updater" or something, instead of the build/compilation, per se. If so, can pom updater is there a bug in pom updater, or is it simply required that bundles be "resolvable" in a certain way? See attached list. If anyone thinks these are important to fix, I could provide separate bugs for (for Luna, only) against each repository. Perhaps even patches, perhaps even test builds :)
FWIW, I did confirm "manually" (by unzipping and invoking 'file' on class files) that rt.equinox.bundles/bundles/org.eclipse.equinox.transforms.hook specifies a BREE of 1.4, but was compiled to 1.5 byte codes. CSVParser.class: compiled Java class data, version 49.0 (Java 1.5) LazyInputStream.class: compiled Java class data, version 49.0 (Java 1.5) LazyInputStream$InputStreamProvider.class: compiled Java class data, version 49.0 (Java 1.5) ProxyStreamTransformer.class: compiled Java class data, version 49.0 (Java 1.5) StreamTransformer.class: compiled Java class data, version 49.0 (Java 1.5) TransformedBundleEntry.class: compiled Java class data, version 49.0 (Java 1.5) TransformedBundleFile$1.class: compiled Java class data, version 49.0 (Java 1.5) TransformedBundleFile.class: compiled Java class data, version 49.0 (Java 1.5) TransformerHook.class: compiled Java class data, version 49.0 (Java 1.5) TransformerList.class: compiled Java class data, version 49.0 (Java 1.5) TransformInstanceListData.class: compiled Java class data, version 49.0 (Java 1.5) TransformTuple.class: compiled Java class data, version 49.0 (Java 1.5)
(In reply to comment #1) > FWIW, I did confirm "manually" (by unzipping and invoking 'file' on class > files) that > rt.equinox.bundles/bundles/org.eclipse.equinox.transforms.hook > specifies a BREE of 1.4, but was compiled to 1.5 byte codes. I opened equinox bug 412770 to address getting the transforms.hook bundle fixed up.
This patch https://git.eclipse.org/r/#/c/16182/ removes duplicated executionEnvironments from P2 (1.5 is declared in P2 parent pom). Please review.
(In reply to Krzysztof Daniel from comment #3) > This patch https://git.eclipse.org/r/#/c/16182/ removes duplicated > executionEnvironments from P2 (1.5 is declared in P2 parent pom). Please > review. This seems to cover all except rt.equinox.p2/org.eclipse.equinox.p2.releng/org.eclipse.equinox.p2-parent/pom.xml. I'm not sure we want to change the parent yet, so I'll release this.
(In reply to Ian Bull from comment #4) > (In reply to Krzysztof Daniel from comment #3) > > This patch https://git.eclipse.org/r/#/c/16182/ removes duplicated > > executionEnvironments from P2 (1.5 is declared in P2 parent pom). Please > > review. > > This seems to cover all except > rt.equinox.p2/org.eclipse.equinox.p2.releng/org.eclipse.equinox.p2-parent/ > pom.xml. I'm not sure we want to change the parent yet, so I'll release this. I (think) I've released this. This is my first attempt with Gerrit, so please let me know if I missed anything. http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=9c1a0f300d694ba8aaba1a0499cb999630d49297
Looks released to me. FWIW this is the gerrit workflow I like to use: - When ready to start reviewing, rebase the change from gerrit UI. This creates a new change set - Fetch that change into Eclipse, review, test, verify, etc - If everything looks good, use the gerrit UI to accept and push the review - Back in Eclipse, switch back to master, pull, and delete the local gerrit branch -> With this workflow, you know what is getting pushed to master is exactly matching what you tested locally. If someone released something while you were reviewing, then the push from gerrit would fail and you need to rebase and review again. However because you are actually pushing into master from gerrit, the gerrit tool is happy and marks the issue as merged.
(In reply to David Williams from comment #0) > Created attachment 232669 [details] > list of 38 bundles that specify custom <executionEnvironment> > > I'll attach full list, with my "annotations" for each, but I'd estimate at > least > half of the cases should not need to specify a custom <executionEnvironment> > ... and half of that half would be better fixed by specifying a BREE in the > MANIFEST.MF file (mostly examples and tests) and then using "standard" > pom.xml. I removed it for 'org.eclipse.jdt.junit.runtime' with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=d4f8c94078db79a5389472926025f7938674cf5d
Fixed for 'org.eclipse.core.expressions' with http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=33036c3d0cf786b7adbac530c35d5b1f2426bc8b
I wanted to note, things are "better now" that they were when this bug was first opened. Begining type Tycho 22 (we use 0.23.1 now) Tycho changed to use the "first BREE in the list" like PDE does. It used to "pick the lowest" so we had to tell it we did not want the lowest used, so had to specify the first in the list. This is described in bug 435313.
(In reply to David Williams from comment #9) > I wanted to note, things are "better now" that they were when this bug was > first opened. Begining type Tycho 22 (we use 0.23.1 now) Tycho changed to > use the "first BREE in the list" like PDE does. It used to "pick the lowest" > so we had to tell it we did not want the lowest used, so had to specify the > first in the list. > > This is described in bug 435313. Better probably. But the recent migration of equinox.cm.tests failed to compile because of executionEnvironment in the pom which had to be removed for the proper one to be picked. https://hudson.eclipse.org/platform/job/rt.equinox.bundles-Gerrit/297/console for details.
I fixed the platform branding bundle. I listed several in manifest, nothing in build.properties, and 1.4 was listed first, so no longer a need to specify 1.4 in the pom. (Most branding bundles do not even need BREEs, if they are "resource only", but this one does have some code in it). http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=2d2f431338eba06442cedc96be67bc64efd13d57
From what I can see, 5 bundles are left with a <executionEnvironment> specified. I think 2 or 3 are not needed. The remaining two or three might take some thought or work to. The most obvious cases to remove: = = = = = org.eclipse.update.configurator in pom: <!-- observed BREE as of Juno --> <executionEnvironment>J2SE-1.4</executionEnvironment> in Manifest.mf Bundle-RequiredExecutionEnvironment: J2SE-1.4, CDC-1.0/Foundation-1.0, J2SE-1.3 Nothing in build.properties. = = = = = org.eclipse.update.core POM: Bundle-RequiredExecutionEnvironment: J2SE-1.4, CDC-1.1/Foundation-1.1 MANIFEST: Bundle-RequiredExecutionEnvironment: J2SE-1.4, CDC-1.1/Foundation-1.1 = = = = = org.eclipse.equinox.log POM: <!-- src/org/eclipse/equinox/log/internal/ExtendedLogEntryImpl.java calls Thread.getId, which was introduced in JDK 1.5 --> <executionEnvironment>J2SE-1.5</executionEnvironment> MANIFEST: Bundle-RequiredExecutionEnvironment: J2SE-1.5, OSGi/Minimum-1.2, CDC-1.1/Foundation-1.1, J2SE-1.4 build.properties: javacSource=1.3 javacTarget=1.2 It is the build.properties I do not understand, in equinox.log. Does that make any sense, or should the "javac" values be removed along with the POM EE of 1.5? = = = = org.eclipse.equinox.bidi POM: <!-- Build java profile J2SE-1.3 set in build.properties does not provide OSGi/Minimum-1.2 defined in bundle manifest. Probably need to report this to the equinox team to reconsile the two, but for now just override build profile in pom.xml. --> <executionEnvironment>OSGi/Minimum-1.2</executionEnvironment> MANIFEST: Bundle-RequiredExecutionEnvironment: OSGi/Minimum-1.2 build.properites: jre.compilation.profile = J2SE-1.3 I have no idea why org.eclipse.equinox.bidi would need to be at such low levels of EE. Seems easiest to me just to move manifest up to 1.3 (or, even 1.4?) and remove the rest. But, this is one that "takes some tought and work". = = = = = eclipse.platform.swt.binaries This pom, is the "repository pom", and it seems to me that currently is it purely a labor saving device so the BREE is not have to be specified in eacy fragment. That get's them compiled, but does nothing for "runtime". I'd recommend the SWT Team "try it out" (i.e. setting in each fragment) and seeing if now works. I know a couple of years ago there were problems doing that, but Tycho has fixed some things since then, and, I think SWT has a more consistent requirement.
(In reply to Alexander Kurtakov from comment #10) > Better probably. But the recent migration of equinox.cm.tests failed to > compile because of executionEnvironment ... By "better", I meant "easier to remove" or "less reason to have in POM".
Fix for update.configurator http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=fc85a7122f58038b3851b3937a716795572ec755 I remembered on this one, and should remind others if it is a non-branding bundle, and you change ONLY the pom.xml file, then the bundle must be "touched" in some way. Either by incrementing the version in MANIFEST (and POM) or by making a note in "forceQualifierUpdates.txt".
Fix for update core: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=8daf46545c74e1872d8badadedcdc84657dc77d9
I have opened bug 491565 for the two equinox cases and bug 491566 for the SWT case.
(In reply to Dani Megert from comment #8) > Fixed for 'org.eclipse.core.expressions' with > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > ?id=33036c3d0cf786b7adbac530c35d5b1f2426bc8b Dani, I believe this bundle needs a service increment. From a quick peek it seems the same version as in 4_5_maintenance. And if not that, then it at least needs to be "touched", or else qualifier will not increment due to "pom only" change.
(In reply to David Williams from comment #17) > (In reply to Dani Megert from comment #8) > > Fixed for 'org.eclipse.core.expressions' with > > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > > ?id=33036c3d0cf786b7adbac530c35d5b1f2426bc8b > > Dani, I believe this bundle needs a service increment. From a quick peek it > seems the same version as in 4_5_maintenance. And if not that, then it at > least needs to be "touched", or else qualifier will not increment due to > "pom only" change. It should have been increased before when real changes went into master. I've fixed this with http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=2b2a14ef43ceffcd59b07bdcdd745570c771b98d
With Equinox now fixed, I am going to close this umbrella bug as fixed. I am doing this even though the SWT bug 491566 is still open. I can not tell from the remarks there if they agree it should be changed, or if they believe it is correct as is. But either way, I think we in releng have tracked this for long enough.
