Community
Participate
Working Groups
Created attachment 219563 [details] proposed changes to p2 pom.xml files Many Platform bundles were not built using the same bundle runtime execution environment as official Juno versions of the bundles. In many cases this was due to inappropriate default execution environment configured in eclipse-parent/pom.xml and the fix is simply let Tycho use bundle minimal runtime execution environment during the build. At least in some cases I do not have good explanation why Juno was built using specific BREE and I forced Tycho configuration to producing matching output.
(In reply to comment #0) > > Many Platform bundles were not built using the same bundle runtime execution > environment as official Juno versions of the bundles. > Are these listed or summarized somewhere? I looked in a few files in the zip and didn't see any obvious "pointers" to that you mean, so I may simple not know how to read them. Thanks,
(In reply to comment #1) > (In reply to comment #0) > > > > Many Platform bundles were not built using the same bundle runtime execution > > environment as official Juno versions of the bundles. > > > > Are these listed or summarized somewhere? I looked in a few files in the zip > and didn't see any obvious "pointers" to that you mean, so I may simple not > know how to read them. > This is the problem the attached patch is meant to fix. First, I removed default J2SE-1.4 forced with eclipse-parent/pom.xml configuration. Then I went through all projects and adjusted project-level configuration to match Juno as necessary. My recommendation is to review these adjustments (added pom.xml lines in the attached diff) to make sure they actually make sense.
Created attachment 219762 [details] proposed changes to cbi pom.xml files updated pom.xml file diffs to generate correct classes in nested jar files
I tested and pushed the patch to CBI platform repos. R4 platform-aggregator: http://git.eclipse.org/c/cbi/platform-aggregator.git/commit/?h=Juno_RC4_R4&id=c33bf1f2caa653ced8eb429a6b9fbbe7bde2a0af eclipse.jdt.debug: http://git.eclipse.org/c/cbi/eclipse.jdt.debug.git/commit/?h=Juno_RC4&id=bf1ab19f9ea620559147ba670561eb6d294df70d eclipse.jdt.ui: http://git.eclipse.org/c/cbi/eclipse.jdt.ui.git/commit/?h=Juno_RC4&id=c34fc7dca66027ebb126ae5febe56e5a60f89a41 R4 eclipse.platform: http://git.eclipse.org/c/cbi/eclipse.platform.git/commit/?h=Juno_RC4_R4&id=e64f6d55520bf03f16cd7c5cba6f5a944c5d0ae5 R4 eclipse.platform.releng: http://git.eclipse.org/c/cbi/eclipse.platform.releng.git/commit/?h=Juno_RC4_R4&id=e94c602d28f0657737d546212ca9437190c87627 eclipse.platform.runtime: http://git.eclipse.org/c/cbi/eclipse.platform.runtime.git/commit/?h=Juno_RC4&id=0bf429e916c83cf3447f1aa249a668c6f9a63136 R4 eclipse.platform.swt.binaries: http://git.eclipse.org/c/cbi/eclipse.platform.swt.binaries.git/commit/?h=Juno_RC4_R4&id=574ae0dc31580092f0b7fa196365f84dae5a3083 eclipse.platform.team: http://git.eclipse.org/c/cbi/eclipse.platform.team.git/commit/?h=Juno_RC4&id=aa824ec70c55d1be75425bbf44312cd57f54452f eclipse.platform.ua: http://git.eclipse.org/c/cbi/eclipse.platform.ua.git/commit/?h=Juno_RC4&id=b08864f3ab9a7346255acae882037377acdaf4c5 R4 eclipse.platform.ui: http://git.eclipse.org/c/cbi/eclipse.platform.ui.git/commit/?h=Juno_RC4_R4&id=424aa15565beff61a0a23ded55d803d6101eebdc rt.equinox.bundles: http://git.eclipse.org/c/cbi/rt.equinox.bundles.git/commit/?h=Juno_RC4&id=26516052d73a8be7ca771aa58b4a275b770e2772 rt.equinox.framework: http://git.eclipse.org/c/cbi/rt.equinox.framework.git/commit/?h=Juno_RC4&id=a75d28fa0b9a9e977164a7a839cdcbf3aa3c2444 rt.equinox.p2: http://git.eclipse.org/c/cbi/rt.equinox.p2.git/commit/?h=Juno_RC4&id=7ecdb48d592cbf6035ae1b41ab6e90122e3add14
I pushed the patches into the R3 branch as well. I did have to make one change in addition to the patches though since building with -Pbree-libs caused a Import error on package java.nio: http://git.eclipse.org/c/cbi/eclipse.platform.ui.git/commit/?h=Juno_RC4_R3&id=895a606b35216204e7a583f0615361586dea7f21 When I ran a comparison I found 2 bundles still having issues. org.eclipse.help.appserver: org/eclipse/help/internal/appserver/AppserverPlugin.class: different org/eclipse/help/internal/appserver/AppserverResources.class: different org/eclipse/help/internal/appserver/DevClassPathHelper.class: different org/eclipse/help/internal/appserver/IWebappServer.class: different org/eclipse/help/internal/appserver/PluginClassLoaderWrapper.class: different org/eclipse/help/internal/appserver/WebappManager.class: different org/eclipse/help/internal/appserver/package.html: not present in baseline org.eclipse.test: org/eclipse/test/EclipseTestRunner.class: different In the case of org.eclipse.help.appserver I noticed forcing J2SE-1.4 fixed the issue but I am hesitant to set that since this same branch is used in the R4 branch and the current pom works fine there.
John, do we still need the help appserver? PW
(In reply to comment #6) > John, do we still need the help appserver? > > PW org.eclipse.help.appserver is only used in 3.x. It was removed from 4.x in the 4.1 release (bug 216322).
I removed help.appserver from master to avoid confusion: http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=ef93f6e228e1e44a8d91cdb2c76ee9dea1d25c6e
(In reply to comment #8) > I removed help.appserver from master to avoid confusion: > > http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/ > ?id=ef93f6e228e1e44a8d91cdb2c76ee9dea1d25c6e I was going to remove this from CBI platform build too but in the CBI build we only have 1 branch for eclipse.platform.ua Juno_RC4 which is used by both the R3 and R4 branches of platform-aggregator. Should we split this branch into R3 and R4 branches and have R4 based on master and R3 based on R3_8_maintenance branch then?
(In reply to comment #9) > I was going to remove this from CBI platform build too but in the CBI build > we only have 1 branch for eclipse.platform.ua Juno_RC4 which is used by both > the R3 and R4 branches of platform-aggregator. Should we split this branch > into R3 and R4 branches and have R4 based on master and R3 based on > R3_8_maintenance branch then? it seems to me you will have to use 2 different branches to manage this change. PW
I thought the main focus right now was on 4.2.x builds for the purpose of LTS. If this is the case I expect you would be building branch R4_2_maintenance for *all* repositories. If you are doing 3.8.x in LTS then all repositories would build off R3_8_maintenance.
(In reply to comment #11) > I thought the main focus right now was on 4.2.x builds for the purpose of > LTS. If this is the case I expect you would be building branch > R4_2_maintenance for *all* repositories. If you are doing 3.8.x in LTS then > all repositories would build off R3_8_maintenance. Ignore my comment, I wasn't thinking clearly. Need my coffee. This repository does not yet have an R4_2_maintenance branch, but I think it will need one to manage this change for LTS.
I split the Juno_RC4 branch of eclipse.platform.ua into 2 new branches. Juno_RC4_R3 Juno_RC4_R4 I went ahead and removed the pom for the org.eclipse.help.appserver per comment #7.
(In reply to comment #13) > I split the Juno_RC4 branch of eclipse.platform.ua into 2 new branches. > > Juno_RC4_R3 > Juno_RC4_R4 > > > I went ahead and removed the pom for the org.eclipse.help.appserver per > comment #7. The commit: http://git.eclipse.org/c/cbi/eclipse.platform.ua.git/commit/?h=Juno_RC4_R4&id=544bff4974ab10a76652481bc41d064c4b5f943d
(In reply to comment #5) > In the case of org.eclipse.help.appserver I noticed forcing J2SE-1.4 fixed > the issue but I am hesitant to set that since this same branch is used in > the R4 branch and the current pom works fine there. I pushed in a patch to force org.eclipse.help.appserver to use J2SE-1.4 to clear up the classes being different. http://git.eclipse.org/c/cbi/eclipse.platform.ua.git/commit/?h=Juno_RC4_R3&id=70f91bd40bcce8de88e3b2f3ca9523711b359b61
I have branched eclipse.platform.ua to create R4_2_maintenance. I have removed org.eclipse.help.appserver in the R4_2_maintenance branch.
(In reply to comment #16) > I have branched eclipse.platform.ua to create R4_2_maintenance. I have > removed org.eclipse.help.appserver in the R4_2_maintenance branch. I am against maintaining two branches just because we want to get rid of the no longer built bundle. It means that each UA developer has to know he must apply fixes (esp. security fixes) and it is just more unnecessary work. From the Platform UI split we learned how easy it is to forget this.
Um, our existing web site seems to be gone: http://www.eclipse.org/eclipse/ Do we have to migrate now to get it back? :)
Please ignore previous comment. Wrong bug.
(In reply to comment #17) > (In reply to comment #16) > > I have branched eclipse.platform.ua to create R4_2_maintenance. I have > > removed org.eclipse.help.appserver in the R4_2_maintenance branch. > > I am against maintaining two branches just because we want to get rid of the > no longer built bundle. It means that each UA developer has to know he must > apply fixes (esp. security fixes) and it is just more unnecessary work. From > the Platform UI split we learned how easy it is to forget this. Just a bumb question, why are you not using Profiles for this ? inside each profile ( 3.8 and 4.2 ) , you can adjust the modules ( ie bundles ) to build for each version, using the same source code.
(In reply to comment #20) > > Just a bumb question, why are you not using Profiles for this ? > inside each profile ( 3.8 and 4.2 ) , you can adjust the modules ( ie > bundles ) to build for each version, using the same source code. Yup, that's what we want :-) Thahn, could we do it that way instead? PW
(In reply to comment #21) > (In reply to comment #20) > > > > Just a bumb question, why are you not using Profiles for this ? > > inside each profile ( 3.8 and 4.2 ) , you can adjust the modules ( ie > > bundles ) to build for each version, using the same source code. > > Yup, that's what we want :-) > > Thahn, could we do it that way instead? > > PW Just want to be clear. Is the suggestion to modify just the one repo eclipse.platform.ua to handle the difference in modules via profiles?
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) > > > > > > Just a bumb question, why are you not using Profiles for this ? > > > inside each profile ( 3.8 and 4.2 ) , you can adjust the modules ( ie > > > bundles ) to build for each version, using the same source code. > > > > Yup, that's what we want :-) > > > > Thahn, could we do it that way instead? > > > > PW > > Just want to be clear. Is the suggestion to modify just the one repo > eclipse.platform.ua to handle the difference in modules via profiles? Yes. There are actually several repositories in this position. At least eclipse.platform.runtime and eclipse.platform repositories have different sets of bundles being built from a common branch.
Thahn, would it be possible to have the default (a.k.a master) work without the module and only require the profile in the 3.x case? Or is that what your patch on cbi-dev implies? PW
(In reply to comment #24) > Thahn, would it be possible to have the default (a.k.a master) work without > the module and only require the profile in the 3.x case? Or is that what > your patch on cbi-dev implies? > > > > PW Yes, that's what the patch currently does.
Created attachment 220408 [details] Patch for org.eclipse.help.appserver Attached patch will build org.eclipse.help.appserver if the file platform-3.8 exists in the platform-aggregator repo. This will allow the build to know if it is building from the 3.8 branch or the 4.2 branch and select the modules accordingly.
(In reply to comment #23) > Yes. There are actually several repositories in this position. At least > eclipse.platform.runtime and eclipse.platform repositories have different > sets of bundles being built from a common branch. Is there a list somewhere of what bundles are built in the eclipse.platform.runtime depending on if we're building 3.8 or 4.2? In the case of eclipse.platform repo currently we are rebased against upstream's R3 or R4 branches respectively.
(In reply to comment #27) > Is there a list somewhere of what bundles are built in the > eclipse.platform.runtime depending on if we're building 3.8 or 4.2? 3.8 only <module>bundles/org.eclipse.core.boot</module> <module>bundles/org.eclipse.core.runtime.compatibility.auth</module> 4.2 only <module>bundles/org.eclipse.e4.core.contexts</module> <module>bundles/org.eclipse.e4.core.di</module> <module>bundles/org.eclipse.e4.core.di.extensions</module> <module>bundles/org.eclipse.e4.core.services</module> <module>tests/com.google.code.atinject.tck</module> <module>tests/org.eclipse.e4.core.tests</module> <module>tests/org.eclipse.e4.core.tests.services</module> both 3.8 and 4.2 <module>bundles/org.eclipse.core.contenttype</module> <module>bundles/org.eclipse.core.expressions</module> <module>bundles/org.eclipse.core.jobs</module> <module>bundles/org.eclipse.core.runtime</module> <module>bundles/org.eclipse.core.runtime.compatibility</module> <module>bundles/org.eclipse.core.runtime.compatibility.registry</module> <module>bundles/org.eclipse.core.tools</module> <module>features/org.eclipse.core.runtime.feature</module> <module>features/org.eclipse.core.tools-feature</module> <module>tests/org.eclipse.core.expressions.tests</module> <module>tests/org.eclipse.core.tests.harness</module> <module>tests/org.eclipse.core.tests.runtime</module>
Created attachment 220464 [details] Patch for org.eclipse.help.appserver
Created attachment 220465 [details] Patch for eclipse.platform.runtime
(In reply to comment #28) > 3.8 only > > <module>bundles/org.eclipse.core.boot</module> > <module>bundles/org.eclipse.core.runtime.compatibility.auth</module> I was not able to build 4.2 without including org.eclipse.core.runtime.compatibility.auth so I had to put it in the combined 3.8 and 4.2 category. Upon closer inspection of "org.eclipse.core.runtime" bundle I discovered it is pulling in the "org.eclipse.core.runtime.compatibility.auth" bundle. Is this expected?
(In reply to comment #31) > I was not able to build 4.2 without including > org.eclipse.core.runtime.compatibility.auth so I had to put it in the > combined 3.8 and 4.2 category. Upon closer inspection of > "org.eclipse.core.runtime" bundle I discovered it is pulling in the > "org.eclipse.core.runtime.compatibility.auth" bundle. > > Is this expected? No. org.eclipse.core.runtime.compatibility.auth should definitely not be in 4.2 builds. This bundle has some obsolete encryption technology that causes export control problems for some products. There is an optional dependency on it from org.eclipse.core.runtime, but it is optional and there is no compile-time dependency.
(In reply to comment #26) > Created attachment 220408 [details] > Patch for org.eclipse.help.appserver > > Attached patch will build org.eclipse.help.appserver if the file > platform-3.8 exists in the platform-aggregator repo. This will allow the > build to know if it is building from the 3.8 branch or the 4.2 branch and > select the modules accordingly. This patch has now been applied to the CBI eclipse.platform.ua repo. http://git.eclipse.org/c/cbi/eclipse.platform.ua.git/commit/?h=JunoSR1_RC1&id=8a5b1a38311bbccea25015cdc1480536f82156d8
(In reply to comment #32) > (In reply to comment #31) > > I was not able to build 4.2 without including > > org.eclipse.core.runtime.compatibility.auth so I had to put it in the > > combined 3.8 and 4.2 category. Upon closer inspection of > > "org.eclipse.core.runtime" bundle I discovered it is pulling in the > > "org.eclipse.core.runtime.compatibility.auth" bundle. > > > > Is this expected? > > No. org.eclipse.core.runtime.compatibility.auth should definitely not be in > 4.2 builds. This bundle has some obsolete encryption technology that causes > export control problems for some products. There is an optional dependency > on it from org.eclipse.core.runtime, but it is optional and there is no > compile-time dependency. Looks like Tycho by default requires all bundles even optional ones but I was able to make Tycho ignore optional bundles by adding the following to the org.eclipse.core.runtime pom file. <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <configuration> <dependency-resolution> <optionalDependencies>ignore</optionalDependencies> </dependency-resolution> </configuration> </plugin> reference: http://wiki.eclipse.org/Tycho/Release_Notes/0.14 I pushed into the CBI eclipse.platform.runtime repo the modifications to have the repo only build the required modules based on what platform version is being built. http://git.eclipse.org/c/cbi/eclipse.platform.runtime.git/commit/?h=JunoSR1_RC1&id=1e5460e7f852a901a28239eaa4b510a66d37d467
John, can we revert the splitting of UA?
(In reply to comment #35) > John, can we revert the splitting of UA? Done: http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?h=R4_2_maintenance&id=de266e733bfa89b4470e1fe8f6c95a589f97279d I should also delete the R4_2_maintenance branch for UA, but here is a pointer to the current branch tip for reference: http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?h=R4_2_maintenance&id=a6688ab943564b679993c416bba1d3dff56827ee
(In reply to comment #36) > (In reply to comment #35) > > John, can we revert the splitting of UA? > > Done: > > http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/ > ?h=R4_2_maintenance&id=de266e733bfa89b4470e1fe8f6c95a589f97279d > > I should also delete the R4_2_maintenance branch for UA, but here is a > pointer to the current branch tip for reference: > > http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/ > ?h=R4_2_maintenance&id=a6688ab943564b679993c416bba1d3dff56827ee I've deleted the 'R4_2_maintenance' branch now.
Why is the directive in the 'pom.xml' 'executionEnvironment'? This seems wrong to me because the BREE is as specified in the manifest, but some other Java version is used to *build* the bundle.
(In reply to comment #38) > Why is the directive in the 'pom.xml' 'executionEnvironment'? This seems > wrong to me because the BREE is as specified in the manifest, but some other > Java version is used to *build* the bundle. I am not sure I understand the question. Generally, Tycho uses bundle minimum declared BREE for all aspects of the build, so JDK used by the build itself does not really matter. There are however few project where BREE declared in bundle manifest or in build.properties cannot be used to build the project and I had to force different execution environment in pom.xml. I can provide more detailed answer, if you are asking about specific project(s).
(In reply to comment #39) > (In reply to comment #38) > > Why is the directive in the 'pom.xml' 'executionEnvironment'? This seems > > wrong to me because the BREE is as specified in the manifest, but some other > > Java version is used to *build* the bundle. > > I am not sure I understand the question. My main point is about the property name in the POM. It is a *build* related property and has nothing to do with the execution environment. Something like "jre.compilation.profile" or "compiler.compliance.level" would be more suitable IMO. > Generally, Tycho uses bundle > minimum declared BREE for all aspects of the build, so JDK used by the build > itself does not really matter. There are however few project where BREE > declared in bundle manifest or in build.properties cannot be used to build > the project Why can't it build? If it is a real-world limitation (I agree it could be hard to get a 1.3 JRE ;-), wouldn't we better change the project's BREE then? That would not be an issue for the junit.runtime project and I'd prefer that over the suggested pom change.
(In reply to comment #40) > Why can't it build? If it is a real-world limitation (I agree it could be > hard to get a 1.3 JRE ;-), wouldn't we better change the project's BREE > then? That would not be an issue for the junit.runtime project and I'd > prefer that over the suggested pom change. I've done that now.
(In reply to comment #40) > > > Generally, Tycho uses bundle > > minimum declared BREE for all aspects of the build, so JDK used by the build > > itself does not really matter. There are however few project where BREE > > declared in bundle manifest or in build.properties cannot be used to build > > the project > > Why can't it build? If it is a real-world limitation (I agree it could be > hard to get a 1.3 JRE ;-), wouldn't we better change the project's BREE > then? That would not be an issue for the junit.runtime project and I'd > prefer that over the suggested pom change. You can see bug 386266 for some of the responses I got from the platform team. Otherwise, yes, I think it is a good idea to remove unrealistic minimum BREE.
(In reply to comment #42) > (In reply to comment #40) > > > > > Generally, Tycho uses bundle > > > minimum declared BREE for all aspects of the build, so JDK used by the build > > > itself does not really matter. There are however few project where BREE > > > declared in bundle manifest or in build.properties cannot be used to build > > > the project > > > > Why can't it build? If it is a real-world limitation (I agree it could be > > hard to get a 1.3 JRE ;-), wouldn't we better change the project's BREE > > then? That would not be an issue for the junit.runtime project and I'd > > prefer that over the suggested pom change. > > You can see bug 386266 for some of the responses I got from the platform > team. Otherwise, yes, I think it is a good idea to remove unrealistic > minimum BREE. Agreed.
Please re-open if this is still relevant.
