Community
Participate
Working Groups
The p2 metadata for "org.eclipse.rcp.configuration_root.cocoa.macosx.x86" "org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64" IUs is creating a symlink at install time but does not have an "uninstall" instruction to remove it when uninstalled. metadata. Here is the "org.eclipse.rcp.configuration_root.cocoa.macosx.x86" metadata <unit id="org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64" version="1.0.0.M20130204-1200"> <provides size="1"><provided namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64" version="1.0.0.M20130204-1200"/></provides><filter> (&(osgi.arch=x86_64)(osgi.os=macosx)(osgi.ws=cocoa)) </filter><artifacts size="1"><artifact classifier="binary" id="org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64" version="1.0.0.M20130204-1200"/></artifacts><touchpoint id="org.eclipse.equinox.p2.native" version="1.0.0"/><touchpointData size="3"><instructions size="2"><instruction key="install"> unzip(source:@artifact, target:${installFolder}); </instruction><instruction key="uninstall"> cleanupzip(source:@artifact, target:${installFolder}); </instruction></instructions><instructions size="1"><instruction key="configure"> ln(linkTarget:Eclipse.app/Contents/MacOS/eclipse,targetDir:${installFolder},linkName:eclipse); </instruction></instructions><instructions size="1"><instruction key="install"> chmod(targetDir:${installFolder}, targetFile:Eclipse.app/Contents/MacOS/eclipse, permissions:755); </instruction></instructions></touchpointData></unit>
This is likely to be an issue with the product definition that omits the unlinking
Our current "configuration" for Kepler is similar, if not same. But, we only specify the "link" via a root directive in build.properties files. root.macosx.cocoa.x86_64.permissions.755=Eclipse.app/Contents/MacOS/eclipse root.macosx.cocoa.x86_64.link=Eclipse.app/Contents/MacOS/eclipse,eclipse Pascal, how do these "root directive" make their way to "p2 publisher"? Does it process them directly (in which case, I'd say p2 publisher bug/enhancement request) or is there some "front end" that translates them? Previously PDE (which must have not been include unconfigure either) or Tycho?
I remember we had to zip up our own mac product because the maven provided zip wasn't able to create a link correctly in the product file. Is this the same thing, did it create a copy instead of a link? Or is this unrelated (the link(*) operation is there, just not the unlink)? PW
(In reply to comment #4) > I remember we had to zip up our own mac product because the maven provided > zip wasn't able to create a link correctly in the product file. > > Is this the same thing, did it create a copy instead of a link? Or is this > unrelated (the link(*) operation is there, just not the unlink)? > > PW It's the latter. Recall the "link" was there "on disk" when built, (since specified in metadata) but did not survive the tarring. But there is no "unlink" operation, in metadata. I'm assuming I could "force" one to be in our p2.inf, see http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/sdk/sdk.p2.inf but a) not sure exactly what it should be, and b) just seems it should be automatic compliment of the root directive, which we specify elsewhere, see http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/rcp.config/build.properties#n59
Just ran across this tonight, so wanted to document links so I won't forget ... http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_actions_touchpoints.html http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_actions_touchpoints.html So, our "compliment" to creating the link, <instructions size="1"> <instruction key="configure"> ln(linkTarget:Eclipse.app/Contents/MacOS/eclipse,targetDir:${installFolder},linkName:eclipse); ... would be something like <instructions size="1"> <instruction key="unconfigure"> remove(targetDir:${installFolder},linkName:eclipse); ... I'll have to play with it a bit. Now, let me ask a question I you'd think I should know the answer to ... how do you install and uninstall Eclipse on the Mac? I always untar and delete directories when I'm done with something. Thanks,
Created attachment 242677 [details] possible solution I believe the fix (workaround) for this bug is to add ,remove(targetDir:${installFolder},path:eclipse) to the unconfigure statement in the product p2.inf files. I say "work around" since technically, it is Tycho that adds the link statement to the metadata, so it is Tycho that should add the "remove link" code. BUT, since the originator has not given the requested steps to reproduce the problem, I am reluctant to put work around in Luna code and for same reason reluctant to open a Tycho bug.
I believe you should be able to use the Eclipse p2 installer to first install and then uninstall Eclipse from a p2 repository on a Mac machine in order to reproduce.
(In reply to Peter Parapounsky from comment #8) > I believe you should be able to use the Eclipse p2 installer to first > install and then uninstall Eclipse from a p2 repository on a Mac machine in > order to reproduce. The "p2 installer" is nothing we build (any longer ... and, not sure what it would take, for Luna stream). I was hoping to do the same with p2 director in "batch mode" (command line script) but haven't had time to try that ... if you happen to have time to provide that ... that ran from binary platform, but installed an instance into another directory, and then showed it's uninstall counter part script removed everything except the symbolic link ... it would help things move along (since I think I know what one fix is). Keep in mind, though, that "the fix" really only applies to "fresh installs". If something is already installed without the fix, then I don't think there is anyway to "fix" that retrospectively. As an adopter, you'd have to use --force in a special IU whose purpose was solely to remove it. So, assuming you are talking about only the "fresh install" case, we could test that, if we hade a p2 director script. (I'm sure such things "sound easy" to you ... but ... when we have 100 "easy things" to do ... every little bit helps.). Thanks,
FYI 1, Tycho 0.21 will fix the issue with the symlink (it will be released in a few days). See https://wiki.eclipse.org/Tycho/Release_Notes/0.21#Packaging for more information. FIY 2, I have resuscitated a kind of "p2 agent" - much like the one provided some time ago by equinox (e.g. see http://archive.eclipse.org/equinox/drops/R-3.6.2-201102101200/index.php#Provisioning). It is available on my github https://github.com/mbarbero/p2-admin. It is basically a standalone product that packages all the IApplication provided by p2 and a custom one for managing composite repositories. See the link above for the list. Hope this helps.
(In reply to Mikael Barbero from comment #10) > FYI 1, Tycho 0.21 will fix the issue with the symlink (it will be released > in a few days). See > https://wiki.eclipse.org/Tycho/Release_Notes/0.21#Packaging for more > information. > > FIY 2, I have resuscitated a kind of "p2 agent" - much like the one provided > some time ago by equinox (e.g. see > http://archive.eclipse.org/equinox/drops/R-3.6.2-201102101200/index. > php#Provisioning). It is available on my github > https://github.com/mbarbero/p2-admin. It is basically a standalone product > that packages all the IApplication provided by p2 and a custom one for > managing composite repositories. See the link above for the list. > > Hope this helps. I'm sure it will help, but to be clear, the fix for symbolic links, in 0.21 does not mention setting a matching "unconfigure" instruction. Tycho currently only sets the "configure" part, based on build.properties ... <instruction key="configure"> ln(linkTarget:Eclipse.app/Contents/MacOS/eclipse,targetDir:${installFolder},linkName:eclipse); but no <instructions size="1"> <instruction key="unconfigure"> remove(targetDir:${installFolder},linkName:eclipse); Guess I'll see for myself soon if that's fixed by 0.21 ... but, if not ... be on the lookout for a new Tycho bug soon :)
You're right, Tycho may not set the unconfigure instruction. Sorry about that. I was a bit over-enthusiastic about the bugfix ;)
While I still don't have a means to verify if a fix works (such as a small p2 director app to unintall the "product") I think a fix would be likely to "do harm". (And, still time to try to write a p2 director app and/or revert, if causes problems). PLUS, long ago I tried to put this fix into the "Equinox RT StarterKit" (planning to try and verify there). But, just tonight, looking at the content.jar/xml file, I see that I did it wrong. ... just a typo, probably? I added units.1.instructions.unconfigure(remove(targetDir:${installFolder},linkName:rt); And see now that results in a touch point instruction of <instruction key='unconfigure(remove(targetDir)'> ${installFolder},linkName:rt); </instruction> The missing "=" throws off the "key". It should be <instruction key='unconfigure'> remove(targetDir:${installFolder},linkName:rt); </instruction> So, while fixing THAT error, I'd like to also add the omission. Peter, as originator, would you be able to verify in the next few days if this change fixes your problem? It would be in a build about Wednesday noon (on 8/27).
I made the change in 2 commits, for each stream (4 total). For the "fix to previous fix" I included exactly that in the comment (along with the usual bug number): http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=3472719d29a73cdc9f0cd79cee3117c02209760b For the case where I added it to 'platform', and 'sdk' I just put the bug number: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=e50437bc26d016aa112953ff1750a9e7787236c1 (Those are for master, R4_4_maintenance easy to find via bug number).
And, just a reminder ... this is my understanding, anyway ... this fix doesn't help if a product is already installed, with the old metadata ... but this will help with products made with 4.4.1 and then later "uninstalled" (or, reinstalled, etc.). For products already installed with old metadata, some "custom solution" will need to be created by the product (such as to have a "dummy IU" installed first, which will then remove the link during the real, next install.
Guess we'll see after getting a build, but I'm not sure the symbolic link is the only problem we have removing a product. Using recent binary platform (one as the "working" one and the other as the target to remove), I used this simple script to "uninstall the target". ./etest/eclipse/eclipse -nosplash -debug -consolelog \ -application org.eclipse.equinox.p2.director \ -destination /Users/davidw/temp/target/eclipse \ -profile SDKProfile \ -uninstallIU org.eclipse.platform.ide So, first, got two exceptions: Uninstalling org.eclipse.platform.ide 4.4.1.M20140826-1635. !SESSION 2014-08-26 23:50:46.164 ----------------------------------------------- eclipse.buildId=4.4.1.M20140826-1635 java.version=1.7.0_45 java.vendor=Oracle Corporation BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -application org.eclipse.equinox.p2.director -destination /Users/davidw/temp/target/eclipse -profile SDKProfile -uninstallIU org.eclipse.platform.ide Command-line arguments: -os macosx -ws cocoa -arch x86_64 -debug -consolelog -application org.eclipse.equinox.p2.director -destination /Users/davidw/temp/target/eclipse -profile SDKProfile -uninstallIU org.eclipse.platform.ide !ENTRY org.eclipse.equinox.p2.core 4 0 2014-08-26 23:50:48.671 !MESSAGE Exception during event notification !STACK 0 java.lang.NullPointerException at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.notify(DirectorApplication.java:688) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) !ENTRY org.eclipse.equinox.p2.core 4 0 2014-08-26 23:50:48.685 !MESSAGE Exception during event notification !STACK 0 java.lang.NullPointerException at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.notify(DirectorApplication.java:688) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) Operation completed in 4254 ms. = = = = = = And, second, it did uninstall a fair, amount, but left quite a bit too, mostly directories, but a few files: ./eclipse ./eclipse/artifacts.xml ./eclipse/configuration ./eclipse/configuration/org.eclipse.equinox.simpleconfigurator ./eclipse/configuration/org.eclipse.equinox.simpleconfigurator/.baseBundlesInfoTimestamp ./eclipse/configuration/org.eclipse.update ./eclipse/configuration/org.eclipse.update/platform.xml ./eclipse/dropins ./eclipse/eclipse ./eclipse/Eclipse.app ./eclipse/Eclipse.app/Contents ./eclipse/Eclipse.app/Contents/MacOS ./eclipse/features ./eclipse/p2 ./eclipse/p2/org.eclipse.equinox.p2.core ./eclipse/p2/org.eclipse.equinox.p2.core/cache ./eclipse/p2/org.eclipse.equinox.p2.core/cache/artifacts.xml ./eclipse/p2/org.eclipse.equinox.p2.core/cache/binary ./eclipse/p2/org.eclipse.equinox.p2.core/cache/binary/org.eclipse.platform.ide.executable.cocoa.macosx.x86_64_4.4.1.M20140826-1635 ./eclipse/p2/org.eclipse.equinox.p2.core/cache/binary/org.eclipse.platform_root_4.4.0.v20140826-1635 ./eclipse/p2/org.eclipse.equinox.p2.core/cache/binary/org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64_1.0.2.v20140826-2027 ./eclipse/p2/org.eclipse.equinox.p2.core/cache/binary/org.eclipse.rcp_root_4.4.0.v20140826-1635 ./eclipse/p2/org.eclipse.equinox.p2.engine ./eclipse/p2/org.eclipse.equinox.p2.engine/.settings ./eclipse/p2/org.eclipse.equinox.p2.engine/.settings/org.eclipse.equinox.p2.artifact.repository.prefs ./eclipse/p2/org.eclipse.equinox.p2.engine/.settings/org.eclipse.equinox.p2.metadata.repository.prefs ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/.settings ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/.settings/org.eclipse.equinox.p2.artifact.repository.prefs ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/.settings/org.eclipse.equinox.p2.metadata.repository.prefs ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions/jvmargs ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.lock ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409089032132.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409089032134.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409089034481.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409089034688.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111367764.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111368267.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111394572.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111395089.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111448236.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111451239.profile.gz ./eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1409111451325.profile.gz ./eclipse/plugins = = = = = = = = = And, yes, it did leave the symbolic link ... but, not sure us removing that will fix up the rest? But, at least now I have a little script to test with.
I'm going to call this verified ... for two reasons (but would appreciate hearing from originator if it actually solves their problem) ... but, I am actually not sure all the "uninstall" issues are fixed, so opened bug 442729 for potential future work. First, I confirmed in "Starter Kit", the unconfigure "key" is now correct: 3854 <instruction key='unconfigure'> 3855 remove(targetDir:${installFolder},linkName:rt); 3856 </instruction> Second, I ran my uninstall script (pasted below) ... on and SDK this time, using p2Director from another SDK of same version, (M20140827-0800) and I'd say "things were better" ... but I have no way of knowing if it solves the originators original problem. (FYI, I learned the -purgeHistory option helps get rid of some more files ... those packed profile history files). But to the point of "symbolic link", what I observed is that the link itself remains, but the executable it points to is now removed. Figure that's a step in the right direction, but again, do not know if that solves originators original issue. And there were still misc. directories and files "left around", but am not sure why. My intuition is that the "order" of some of our operations in our touch points could be improved? But, am not sure. So feel free to re-open (or comment in another bug) but no more is planned here for Luna SR1 ... we are just too close to the end. And, again, at least it was one step in the right direction. Thanks, = = = = = = = $ cat uninstall.sh #!/usr/bin/env bash ./etest/eclipse/eclipse -nosplash -debug -consolelog \ -application org.eclipse.equinox.p2.director \ -destination /Users/davidw/temp/target/eclipse \ -profile SDKProfile \ -purgeHistory \ -uninstallIU org.eclipse.sdk.ide #-listInstalledRoots #-help
With some of what I've learned recently (looking at problematic eclipse.ini location) I am fairly sure I have the metadata action incorrect. I believe the 'remove' action takes only one argument, path (to directory, or file) and not two, as in my original "fix". http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_actions_touchpoints.html Obviously the "two argument" case is doing something, as noted in previous remarks, but a) is not documented and b) is not removing the link, as anticipated. I have also learned, just from observation, that on a Mac, that a "copy" operation on a directory, will not maintain the symbolic links (as Linux does) but converts them to an ordinary file. It is this feature of Mac's OSX that may be at the root of adopter products that build on p2, that after a copy (which can be done as part of an update, to keep a "restore point", that the link may be being converted to an ordinary file. This leads me to believe that force="true" should be used when creating the link, especially on Mac OSX, but can not imagine why it should not also be forced on other OSs. So am re-opening to "look at again", in the sense of experimenting with new found calls/settings ... but, still can not be sure if this really helps original problem or not.
This is commit in maintenance, to correct the "remove" instruction, for the "macosx" touchpoints. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_4_maintenance&id=1353f7fe552b51828296c85854a57b095151fb93
Markus, I went ahead and committed this, so I can do "test builds" soon, but would appreciate a sanity check. I realized, while fixing the obvious "syntax" problem with "remove" that in some cases I had previous put on wrong IU, the one for ! macosx. The fix should only be on "macosx" IUs.
Created attachment 250053 [details] completion of comment 19/20 I don't think I really understand the scenarios where this is used, so I can't test anything. But for consistency with what I read in comment 19 and comment 20, I think these changes should be applied to R4_4_maintenance.
(In reply to Markus Keller from comment #21) > Created attachment 250053 [details] > completion of comment 19/20 > > I don't think I really understand the scenarios where this is used, so I > can't test anything. But for consistency with what I read in comment 19 and > comment 20, I think these changes should be applied to R4_4_maintenance. Agreed. Can't believe the very error I was afraid of making, twice! (putting the action on the ! macosx IU instead of the macosx IU -- hard to read language, I guess. I made similar fixes to master version. The "test" is just to run a script like the one in comment 16, but, agreed. None of us have access to "the real" use-case where the problem appears. So, at best this is "an attempt" to fix it. And, more so, an attempt to fix my obviously incorrect previous attempt. And, to "test" really does need to be in a build ... as far as I know, could not be tested from workspace. I'll run the "test script" once I have a build with these changes in it and as long as "no worse" than previous "uninstall" test (around comment 16) will count this as fixed.
Guess I should have done a "local test" first, with "unofficial" build. Because when I did that, got an IllegalArgumentException: no action found for: org.eclipse.equinox.p2.touchpoint.eclipse.remove. I think that means I need to use fully qualified name: org.eclipse.equinox.p2.touchpoint.natives.remove I'll try that.
(In reply to David Williams from comment #23) > > org.eclipse.equinox.p2.touchpoint.natives.remove > > I'll try that. After that fix, it seems that it performs as well as (or better?) that before, Log: Command-line arguments: -os macosx -ws cocoa -arch x86_64 -debug -consolelog -application org.eclipse.equinox.p2.director -destination /Users/davidw/temp/platform/eclipse -profile SDKProfile -purgeHistory -uninstallIU org.eclipse.platform.ide !ENTRY org.eclipse.equinox.p2.core 4 0 2015-01-20 03:31:58.325 !MESSAGE Exception during event notification !STACK 0 java.lang.NullPointerException at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.notify(DirectorApplication.java:688) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) !ENTRY org.eclipse.equinox.p2.core 4 0 2015-01-20 03:31:58.327 !MESSAGE Exception during event notification !STACK 0 java.lang.NullPointerException at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.notify(DirectorApplication.java:688) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108) at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) !ENTRY org.eclipse.equinox.p2.touchpoint.natives 2 0 2015-01-20 03:32:00.032 !MESSAGE Could not remove temporary backup directory (it is safe to manually delete it and its contents): /var/folders/4l/4r95g72519l8_ncylflrft4m0000gn/T/SDKProfile_2960cf0826e0_c0a80105e5b3 Operation completed in 2529 ms. Files Left: There were 17 files left. And numerous empty directories. (and the "backup"!) But, no "eclipse" executable was left behind. Interestingly, the "backup" was literally the symbolic link (and its target): $ ll /var/folders/4l/4r95g72519l8_ncylflrft4m0000gn/T/SDKProfile_2960cf0826e0_c0a80105e5b3/_/Users/davidw/temp/platform/eclipse/eclipse lrwxrwxr-x 1 davidw staff 34 Jan 20 03:10 /var/folders/4l/4r95g72519l8_ncylflrft4m0000gn/T/SDKProfile_2960cf0826e0_c0a80105e5b3/_/Users/davidw/temp/platform/eclipse/eclipse@ -> Eclipse.app/Contents/MacOS/eclipse
(In reply to David Williams from comment #24) > (In reply to David Williams from comment #23) > > > > > org.eclipse.equinox.p2.touchpoint.natives.remove > > > > I'll try that. > > After that fix, it seems that it performs as well as (or better?) that > before, > In order to get a clean history, I reverted the previous two commits: d5b5df778be76ee416030d4333e71a6b4c9a7d5a 1353f7fe552b51828296c85854a57b095151fb93 And will re-commit the correct version (probably tomorrow, since my workbench just hung up, and I'm tired :)
Did commit to R4_4_maintenance. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_4_maintenance&id=152e10a26ef5d60536fd936f2145a4c8b24c4c8f and master: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=17a28d84108973f00bd9c8c67ce11d24bac62a69
> java.lang.NullPointerException > at > org.eclipse.equinox.internal.p2.director.app.DirectorApplication.notify(DirectorApplication.java:688) > > at > org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108) That's bug 387088, where a fix has been committed (though probably incomplete). Fix for errors in R4_4_maintenance after comment 25/26: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_4_maintenance&id=3281c29112116e106c5b0aa70acfc2334bd6a0fd master looks good.
(In reply to Markus Keller from comment #27) > > java.lang.NullPointerException > > at > > org.eclipse.equinox.internal.p2.director.app.DirectorApplication.notify(DirectorApplication.java:688) > > > > at > > org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108) > > That's bug 387088, where a fix has been committed (though probably > incomplete). > > Fix for errors in R4_4_maintenance after comment 25/26: > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?h=R4_4_maintenance&id=3281c29112116e106c5b0aa70acfc2334bd6a0fd > > master looks good. Thank you for catching that error. And, the reference to NPE bug.
(In reply to David Williams from comment #24) > (In reply to David Williams from comment #23) > > > > > org.eclipse.equinox.p2.touchpoint.natives.remove > > > > I'll try that. > > After that fix, it seems that it performs as well as (or better?) that > before, > I'll just note, that I tried same script, using eclipse-sdk, and eclipse-platform, from SR2RC1, and there was no mention of a "backup file" made, and only 15 files remained ... BUT, sure enough, the symbolic link was left, pointing to nothing. I mean, if you do a 'll', you'll see eclipse@ -> Eclipse.app/Contents/MacOS/eclipse but there is nothing at that location. The executable was removed. Just not the link to it. The script I used was !/usr/bin/env bash ./sdk/eclipse/eclipse -nosplash -debug -consolelog \ -application org.eclipse.equinox.p2.director \ -destination ${PWD}/platform/eclipse \ -profile SDKProfile \ -purgeHistory \ -uninstallIU org.eclipse.platform.ide And, should note, I had not actually "ran" the platform in above test. If I do run the workbench, and just close the Intro view, and then close the workbench, and then run the above uninstall script, there are 117 files left (plus, of course, the symbolic link).
