Bugzilla – Full Text Bug Listing
| Summary: | Buckminster is creating touchpoints with the wrong case for the Eclipse launcher | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Ian Bull <irbull> |
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, john.arthorne, mknauer, thomas, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 390756 | ||
|
Description
Ian Bull
I don't understand why a fix that was made in August 2011, and thus has been present when building both Indigo SR1 and SR2 as well as in the Juno release can pop up as a blocker now? Can you please explain? In any case, if someone could please provide a patch for this that is proven to work I would be very grateful and see to that it's incorporated immediately. I'm not in the possession of a Mac OS/X based machine. (In reply to comment #1) > I don't understand why a fix that was made in August 2011, and thus has been > present when building both Indigo SR1 and SR2 as well as in the Juno release > can pop up as a blocker now? Can you please explain? Are we sure that EPP uses the latest Buckminster when building service releases (like SR1 and SR2 for Indigo)? The problem does exist in Juno SR0, but since nobody was 'updating too Juno' this wasn't noticed (looking at the Juno metadata I can see the launcher with the wrong case). Markus, perhaps you can shed some light on this? What versions of Buckminster has been used and when was this problem first discovered? (In reply to comment #3) > What versions of Buckminster has been used and when was this problem > first discovered? The problem has been discovered just now, with people updating their Mac OSX packages from Juno to Juno SR1. All Juno related EPP builds install Buckminster from /home/data/httpd/download.eclipse.org/tools/buckminster/headless-4.2 Juno Release org.eclipse.buckminster.cmdline.product 1.5.0.v20120522-1841. org.eclipse.buckminster.core.headless.feature.feature.group 1.5.0.v20120405-0431. org.eclipse.buckminster.git.headless.feature.feature.group 1.5.0.v20120603-0656. org.eclipse.buckminster.pde.headless.feature.feature.group 1.5.0.v20120405-0829. Juno Service Release 1 org.eclipse.buckminster.cmdline.product 1.5.0.v20120522-1841. org.eclipse.buckminster.core.headless.feature.feature.group 1.5.0.v20120910-1329. org.eclipse.buckminster.git.headless.feature.feature.group 1.5.0.v20120823-1443. org.eclipse.buckminster.pde.headless.feature.feature.group 1.5.0.v20120904-1612. All builds before Juno (i.e. Indigo, Helios, ...) were using a frozen copy and did *not* upgrade to the latest version. Here are the versions of the features used in the build during that time: Indigo SR2 (and probably SR1 and R) + Helios SR2 org.eclipse.buckminster.core.headless.feature_1.3.1.r11579.jar org.eclipse.buckminster.cvs.headless.feature_1.1.0.r11564.jar org.eclipse.buckminster.pde.headless.feature_1.2.1.r11577.jar org.eclipse.equinox.p2.director.feature_1.2.1.v20100819-2107.jar I've created two new p2 sites where I've reverted the capitalization of the executable name. Please test and see if that fixes the problem. If it does, I'll merge it and make it available on our regular site. http://download.eclipse.org/tools/buckminster/headless-4.2-epp http://download.eclipse.org/tools/buckminster/updates-4.2-epp (IDE only) This is the commit: http://git.eclipse.org/c/buckminster/buckminster.git/commit/?id=1693dc86ba0057a0616ab876f528696c4c49ce13 It simply removes the Buckminster version of the method: ApplicationLauncherAction.computeExecutables(String configSpec) I've updated the Buckminster p2 repository URL and started a new build: https://hudson.eclipse.org/hudson/user/mknauer/my-views/view/EPP/job/juno.epp-repository-build/313/ (I won't be able to analyze the results in the next few hours because I'll be travelling...) (In reply to comment #7) > I've updated the Buckminster p2 repository URL and started a new build: > > https://hudson.eclipse.org/hudson/user/mknauer/my-views/view/EPP/job/juno. > epp-repository-build/313/ > > (I won't be able to analyze the results in the next few hours because I'll > be travelling...) We'll need to wait for Markus's (and Ian's?) confirmation, but this "worked for me". I tried an "update" from fresh Juno SR0 JEE EPP package, using the repo from http://build.eclipse.org/technology/epp/epp_repo/juno/epp.build/buildresult/org.eclipse.epp.allpackages.juno.feature_1.5.1-eclipse.feature/site.p2/ and it updated, and it left my eclipse.ini there! (I was surprised to see mx set so low, merely 512m ... I thought it used to be 768m ... but ... different issue as it was that way in Juno SR0, now that I look at it ... a "diff" showed no differences ... I think mx was incremented on some packages ... that'd be a better test ... make sure those get the new values). I tried testing the case where someone has already installed update, and had eclipse.ini removed, and then tried to see if using new test repo would "restore" the eclipse.ini. It didn't work, but I think only because the version wasn't incremented? I installed fresh JEE EPP SR0 package, added the direct site http://download.eclipse.org/technology/epp/packages/juno/SR1/ It updated as expected and removed eclipse.ini as as been reported. Then I added the new "test repo" of http://build.eclipse.org/technology/epp/epp_repo/juno/epp.build/buildresult/org.eclipse.epp.allpackages.juno.feature_1.5.1-eclipse.feature/site.p2/ Then I did "check for updates" and it said "no updates found". Can this be fixed by increasing service version? Qualifer? Of the "mac IUs" only? (In reply to comment #9) > Can this be fixed by increasing service version? Qualifer? Of the "mac IUs" > only? Ideally it would be an upgrade of the "mac IUs" only, but my guess is that we cannot do it on such a fine granularity. Instead I think we need to update the "feature" IUs that represent that package content. But that means that people downloading an existing ready-to-run archive from eclipse.org/downloads will see not only a small update of some IUs in the background, but also an upgrade of the corresponding "feature". I am not sure if this is acceptable and if this means that we need to rebuild all packages. I looked closer, and can confirm the version in the SR1 repo and the build machine test repo both are 1.5.1.20120917-1257 So ... an increment is needed. and then I'll try again. = = = = = = = = I think its acceptable (obviously not ideal) if everyone sees/gets the "update" even for most cases it won't do anything. At Planning Council call yesterday, we decided we'd leave it up to you Markus. Its a lot of work to rebuild the DL packages, let them mirror, etc., and update DL pages ... and maintainers re-vote? ... it will only be an issue for 3 or 4 months :\ ... I think last time something similar happened (Helios), we lived with the "everyone gets offered the new update". C'est la vie? [Unless, of course, you have the time and energy to re-do them all .... perhaps you should/could ask maintainers on epp list?] (In reply to comment #10) > Ideally it would be an upgrade of the "mac IUs" only, but my guess is that > we cannot do it on such a fine granularity. Instead I think we need to > update the "feature" IUs that represent that package content. > > But that means that people downloading an existing ready-to-run archive from > eclipse.org/downloads will see not only a small update of some IUs in the > background, but also an upgrade of the corresponding "feature". I am not > sure if this is acceptable and if this means that we need to rebuild all > packages. I don't think it would be 'in the background'. If they checked for updates, it would find it, install it, and restart. It would essentially be a no-op (that is the result of the update is a no-op), but the update would look real to all the users. Unless we put out new packages, this is likely unavoidable, but something we need to test. Am I correct in assuming that, from a Buckminster standpoint, the current fix is acceptable? My reason for asking is that I'd like to merge it and do a proper release so that this bug can be resolved. (In reply to comment #13) > Am I correct in assuming that, from a Buckminster standpoint, the current > fix is acceptable? My reason for asking is that I'd like to merge it and do > a proper release so that this bug can be resolved. Thomas, I'm going to put together a small p2 diff tool to check the output of p2 repo. I'll post the results here. That well help ensure that only the MacOS launcher bits were changed (and the versions anything that 'included' them). The results of that should help give Buckminster confidence that this fix is good. New builds available... * http://download.eclipse.org/technology/epp/packages/juno/SR1a.313/ is the one with *unchanged version numbers (+qualifier)* that David already tested in comment #7. I just moved it to the download location to store it in a "safe" place. * http://download.eclipse.org/technology/epp/packages/juno/SR1a.315/ is a new build with updated qualifiers for the features, bundles, all IUs. I checked that they contain only the correct install instruction setLauncherName(name:eclipse) and *not* a capitalized one. I ran a custom diff tool on the metadata before and after this fix. The only difference was the name of the Eclipse launcher (and the version numbers of IUs related to that). This should give us confidence that this change is good. Thanks so much Thomas and Markus! I'll start a new build to get this into our official sites. Fix published. |