Community
Participate
Working Groups
Build Identifier: 20110218-0911 I upgraded Eclipse 3.6.1 to 3.6.2 today, using the "Check for Updates" feature. After the upgrade, it tried to restart Eclipse. But after showing the splash screen for about a minute, it quit with an error in the stdout: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space I tried launching Eclipse a few more times, and got the same error. Then I noticed that the eclipse.ini file was missing. It seems to have been deleted during the update. I know it was there before, because I had increased the memory limit, and set some other options. Once I restored it from a backup, Eclipse launched successfully. But I'm not sure why it got deleted in the first place. Reproducible: Didn't try
Could you please indicate which Eclipse package you were using? In the workspace from which you did the upgrade, is there a .log file that contain relevant information?
I had originally installed eclipse-jee-helios-macosx-cocoa-x86_64.tar.gz. On top of that, I installed a few plugins, including PDT, Subclipse, and EGit. I upgraded to SR1 and later SR2 using "Check for updates". Here's the log from around that time: !SESSION 2011-02-26 10:06:48.032 ----------------------------------------------- eclipse.buildId=M20110210-1200 java.version=1.6.0_22 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /homedir/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /homedir/.eclipse_keyring -showlocation !ENTRY org.eclipse.osgi 4 0 2011-02-26 10:07:20.649 !MESSAGE An error occurred while automatically activating bundle org.eclipse.core.resources (1085). !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.resources.ResourcesPlugin.start() of bundle org.eclipse.core.resources. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:806) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:116) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575) at org.eclipse.equinox.launcher.Main.run(Main.java:1408) Caused by: java.lang.OutOfMemoryError: Java heap space at java.io.DataInputStream.readUTF(DataInputStream.java:644) at java.io.DataInputStream.readUTF(DataInputStream.java:547) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:63) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readTree(DataTreeReader.java:147) at org.eclipse.core.internal.watson.ElementTreeReaderImpl_1.readDelta(ElementTreeReaderImpl_1.java:43) at org.eclipse.core.internal.watson.ElementTreeReader.readDelta(ElementTreeReader.java:86) at org.eclipse.core.internal.watson.ElementTreeReaderImpl_1.readDeltaChain(ElementTreeReaderImpl_1.java:88) at org.eclipse.core.internal.watson.ElementTreeReader.readDeltaChain(ElementTreeReader.java:110) at org.eclipse.core.internal.resources.WorkspaceTreeReader_1.readTrees(WorkspaceTreeReader_1.java:232) at org.eclipse.core.internal.resources.WorkspaceTreeReader_1.readTree(WorkspaceTreeReader_1.java:166) at org.eclipse.core.internal.resources.SaveManager.restoreTree(SaveManager.java:978) at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:665) at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1503) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2134) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:1883) at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:406) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) Root exception: java.lang.OutOfMemoryError: Java heap space at java.io.DataInputStream.readUTF(DataInputStream.java:644) at java.io.DataInputStream.readUTF(DataInputStream.java:547) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:63) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readTree(DataTreeReader.java:147) at org.eclipse.core.internal.watson.ElementTreeReaderImpl_1.readDelta(ElementTreeReaderImpl_1.java:43) at org.eclipse.core.internal.watson.ElementTreeReader.readDelta(ElementTreeReader.java:86) at org.eclipse.core.internal.watson.ElementTreeReaderImpl_1.readDeltaChain(ElementTreeReaderImpl_1.java:88) at org.eclipse.core.internal.watson.ElementTreeReader.readDeltaChain(ElementTreeReader.java:110) at org.eclipse.core.internal.resources.WorkspaceTreeReader_1.readTrees(WorkspaceTreeReader_1.java:232) at org.eclipse.core.internal.resources.WorkspaceTreeReader_1.readTree(WorkspaceTreeReader_1.java:166) at org.eclipse.core.internal.resources.SaveManager.restoreTree(SaveManager.java:978) at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:665) at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1503) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2134) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:1883) at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:406) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) !ENTRY org.eclipse.osgi 4 0 2011-02-26 10:07:20.780 !MESSAGE Application error !STACK 1 java.lang.NoClassDefFoundError: org/eclipse/core/resources/IContainer at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:116) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575) at org.eclipse.equinox.launcher.Main.run(Main.java:1408) Caused by: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.core.resources (1085). at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:121) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 13 more Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.core.resources.ResourcesPlugin.start() of bundle org.eclipse.core.resources. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:806) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) ... 22 more Caused by: java.lang.OutOfMemoryError: Java heap space at java.io.DataInputStream.readUTF(DataInputStream.java:644) at java.io.DataInputStream.readUTF(DataInputStream.java:547) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:63) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readNode(DataTreeReader.java:103) at org.eclipse.core.internal.dtree.DataTreeReader.readTree(DataTreeReader.java:147) at org.eclipse.core.internal.watson.ElementTreeReaderImpl_1.readDelta(ElementTreeReaderImpl_1.java:43) at org.eclipse.core.internal.watson.ElementTreeReader.readDelta(ElementTreeReader.java:86) at org.eclipse.core.internal.watson.ElementTreeReaderImpl_1.readDeltaChain(ElementTreeReaderImpl_1.java:88) at org.eclipse.core.internal.watson.ElementTreeReader.readDeltaChain(ElementTreeReader.java:110) at org.eclipse.core.internal.resources.WorkspaceTreeReader_1.readTrees(WorkspaceTreeReader_1.java:232) at org.eclipse.core.internal.resources.WorkspaceTreeReader_1.readTree(WorkspaceTreeReader_1.java:166) at org.eclipse.core.internal.resources.SaveManager.restoreTree(SaveManager.java:978) at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:665) at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1503) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2134) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:1883) at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:406) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106)
Just to be clear? The update looked like it had been succesful? Is there more in the log?
*** Bug 338313 has been marked as a duplicate of this bug. ***
I also experienced this issue (and submitted bug 338313 as my search terms didn't turn up this one first). In the description I reported that it occurred on both an RCP and JEE based systems (on separate machines). On the second system I watched to see when in the process it was removed; it was there at the penultimate prompt, but by the time the 'Restart Eclipse' prompt rolled around, it was gone. Otherwise, the update was successful. There was no indication of a problem until the restarted Eclipse ran out of heap space.
I have been able to reproduce the pb...
Sometimes I just hate macs... File previousLauncherIni = launcherData.getPreviousLauncherIni(); if (previousLauncherIni != null && !previousLauncherIni.equals(launcherConfigFile)) previousLauncherIni.delete(); launcherData.setLauncherConfigLocation(launcherConfigFile); /Users/Pascal/Eclipse.ini is equal to /Users/Pascal/eclipse.ini....
I don't like them too... Okay, for now I've disabled the Helios SR2 updates of the EPP packages in order to get some time to look into this. If someone wants to reproduce this, (s)he would need to add the following p2 repository manually: http://download.eclipse.org/technology/epp/packages/helios/SR2
Okay, maybe someone with a Mac is now able to play with the proposed solution below. Note: The update to SR2 is currently disabled, so one needs to add the p2 repository manually to the preferences before hitting 'Check for Updates'. If we decide for this solution, I will enable the repo in the EPP composite repository definition. -> Add the following p2 repository to your configuration; it contains the modified metadata with eclipse in small letters: http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed -> Then hit 'Check for Updates'
(In reply to comment #9) > Okay, maybe someone with a Mac is now able to play with the proposed solution > below. Note: The update to SR2 is currently disabled, so one needs to add the > p2 repository manually to the preferences before hitting 'Check for Updates'. > If we decide for this solution, I will enable the repo in the EPP composite > repository definition. > > -> Add the following p2 repository to your configuration; it contains the > modified metadata with eclipse in small letters: > > http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed > > -> Then hit 'Check for Updates' I had the same problem: deleted eclipse.ini. Reinstalled eclipse-java-helios-SR2-macosx-cocoa-x86_64.tar.gz. Added repository. Performed 'Check for Updates'. No updates found. eclipse.ini still present. Thanks to all for identifying and working on this.
(In reply to comment #10) > I had the same problem: deleted eclipse.ini. Reinstalled > eclipse-java-helios-SR2-macosx-cocoa-x86_64.tar.gz. Added repository. > Performed 'Check for Updates'. No updates found. eclipse.ini still present. 'No updates found.' - that's the expected behaviour since you started with a SR2 download. I would be interested in someone testing an update from a fresh SR1 version on a Mac with the above p2 repository.
Following the procedure outlined in Comment #9 against a older Mac helios configuration I had lying around (RCP based): The eclipse.ini was present after the update completed The eclipse.init was updated with the new launcher information There does not appear to be any issue with the update; Eclipse runs correctly 'About Eclipse' now shows (as expected): Eclipse for RCP and RAP Developers Version: Helios Service Release 2 Build id: 20110218-0911
(In reply to comment #12) > The eclipse.ini was present after the update completed > The eclipse.init was updated with the new launcher information That's good news! Thanks for testing!
(In reply to comment #11) > (In reply to comment #10) > > I had the same problem: deleted eclipse.ini. Reinstalled > > eclipse-java-helios-SR2-macosx-cocoa-x86_64.tar.gz. Added repository. > > Performed 'Check for Updates'. No updates found. eclipse.ini still present. > > 'No updates found.' - that's the expected behaviour since you started with a > SR2 download. I would be interested in someone testing an update from a fresh > SR1 version on a Mac with the above p2 repository. I thought that eclipse.ini not being deleted was also part of the fix.
(In reply to comment #14) > (In reply to comment #11) > > (In reply to comment #10) > > > I had the same problem: deleted eclipse.ini. Reinstalled > > > eclipse-java-helios-SR2-macosx-cocoa-x86_64.tar.gz. Added repository. > > > Performed 'Check for Updates'. No updates found. eclipse.ini still present. > > > > 'No updates found.' - that's the expected behaviour since you started with a > > SR2 download. I would be interested in someone testing an update from a fresh > > SR1 version on a Mac with the above p2 repository. > > I thought that eclipse.ini not being deleted was also part of the fix. Because the metadata just got hacked by hand without having changed the version, it is possible that you will not get the IU from the new repo but from the helios one that is still enabled.
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > I had the same problem: deleted eclipse.ini. Reinstalled > > > > eclipse-java-helios-SR2-macosx-cocoa-x86_64.tar.gz. Added repository. > > > > Performed 'Check for Updates'. No updates found. eclipse.ini still present. > > > > > > 'No updates found.' - that's the expected behaviour since you started with a > > > SR2 download. I would be interested in someone testing an update from a fresh > > > SR1 version on a Mac with the above p2 repository. > > > > I thought that eclipse.ini not being deleted was also part of the fix. > > Because the metadata just got hacked by hand without having changed the > version, it is possible that you will not get the IU from the new repo but from > the helios one that is still enabled. Ah! Thank you for the explanation. And again, thanks to all for the quick find and work. I will say when I first noticed that eclipse.ini was gone, I was very perplexed.
I'm trying to test too, on my Mac. Should it have failed with the cpp package too? I loaded a cpp SR1, did 'check for updates' and got 'none found' as expected since you turned them off. I then added the http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed update site but i get "There are no categorized items."
(In reply to comment #17) > I'm trying to test too, on my Mac. Should it have failed with the cpp package > too? Yep, it should have failed. > I loaded a cpp SR1, did 'check for updates' and got 'none found' as expected > since you turned them off. Correct. > I then added the > http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed > update site but i get "There are no categorized items." You need to 'check for updates' again. Then you should get an update of the CPP package. The EPP UI's are not categorized by design, otherwise they would be visible in the standard simultaneous release train features listing in the "Install New Software..." dialog which would be disturbing for he unexperienced user. The experienced user can find them anyway by deselecting 'Group items by category'.
*** Bug 338302 has been marked as a duplicate of this bug. ***
(In reply to comment #18) Ah. so the full Helios repo would have showed something but since this (test) partial repo of epp-only is only epp stuff, the categorized/non-epp stuff isn't there? That makes sense. Worked fine. Updated and restarted correctly.
*** Bug 338308 has been marked as a duplicate of this bug. ***
Created attachment 189961 [details] virgin installed eclipse.ini from an J2EE 64bit Ran into this too and added the virgin installed eclipse.ini from an J2EE install, just to make it easier for anybody to recover who suffered this issue.
Has it been determined yet why the metadata contained "Eclipse.ini" in the first place?
Is the epp.java update still unavailable from check for update? I get no update for my SR1 (eclipse for java developers)
*** Bug 338534 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > *** Bug 338534 has been marked as a duplicate of this bug. *** Thanks, that fixed it for me as well. Here is what I had to do: 1. Add the new URL http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed to the available update sites. 2. Close the dialog 3. Run "Check for Updates" 4. Next, Next, Next, Accept license, Finish.
I have successfully updated Eclipse 3.6.1 for Java EE on Mac OS X 10.6.6 - cocoa x86_64. Adding the SR2.fixed repo worked as expected. Original eclipse.ini was retained. Restarting was not an issue.
Created attachment 190084 [details] launcher name="eclipse" One comment before you read on: I haven't found the root cause for this problem, but I do know that something changed from SR1 to SR2. Candidates for this change are the upstream p2 repositories (Helios + Platform), or a change in the Buckminster internals (yes, that was my fault to delete the local Buckminster 1.1.something repository that was used to generate the p2 metadata for the packages in an attempt to safe disk space; everything is self-hosting except this one so I had to jump to Buckminster 1.2.1). This patch changes the product configuration of *all* packages. In earlier builds the launcher element of the epp.product configuration had no name attribute. My expectation is/was that it takes the default 'eclipse', but maybe this behaviour changed and it derives something from somewhere else (e.g. the branding plug-in comes with an appName=Eclipse). I really cannot say. I changed this now to <launcher name="eclipse"> in the epp.product and the generated content.xml looks good. So, what are we going to do now? At some point I need to enable the update of old SR1 EPP packages to SR2 and I don't won't to wait much longer. Option 1: As Pascal suggested, take the newly generated p2 repository (http://download.eclipse.org/technology/epp/packages/helios/SR2.282) - to me this sounds very risky as I cannot really ensure that it doesn't break anything new. Option 2: Take the hand-modified p2 repository (http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed) that got some positive testing from the community and enable it for everyone. This might have some timestamps in there that were not updated, but I think it will be used only by those who haven't done any updates on Saturday. And those who updated on Saturday were either successful or were using a Mac OSX version and ended up with something that is broken anyway. I would vote for option 2, but I'd like to hear your thoughts.
> Option 2: Take the hand-modified p2 repository > (http://download.eclipse.org/technology/epp/packages/helios/SR2.fixed) that got > some positive testing from the community and enable it for everyone. This might > have some timestamps in there that were not updated, but I think it will be > used only by those who haven't done any updates on Saturday. And those who > updated on Saturday were either successful or were using a Mac OSX version and > ended up with something that is broken anyway. > > I would vote for option 2, but I'd like to hear your thoughts. If we are taking about hand modifying an existing repository to change an existing IU, then I have to give this a big -1. p2 metadata is immutable, and this assumption is used everywhere. If we release the same IU (with the same ID/Version) and different content, then there is no telling what ramifications this will have. For example, I have already sucked this metadata into Yoxos (and I'm sure other people have pulled this data too). This means that we will have the same IU floating around with different content. p2 assumes that if the ID/Version are equal to what is has cached, then everything is up-to-date. I have no objections to hand-modifying p2 metadata, but we need to; 1. Make sure we are releasing a new version of the IU (and the new version is > than the previous version). 2. We need to make this modification before anybody has access to the IUs (as part of the build process for example) 3. We need to ensure that what we modify by hand is correct! (This goes without saying, but it might be more trickier than we think).
Thanks for this feedback, Ian. Based on this feedback and on the discussion in the Planning Council call yesterday I played through various update scenarios this morning without any problems with option 1 (newly generated EPP p2 repository). Successfully tested with http://download.eclipse.org/technology/epp/packages/helios/SR2.282: Windows 32-bit - R->SR2 update: RCP/RAP package - SR1->SR2 update: JEE package - SR2->SR2 update: PHP package Mac OSX 64-bit - R->SR2 update: JavaScript package - SR1->SR2 update: RCP/RAP package - SR2->SR2 update: Java package Linux 32-bit - SR2->SR2 update: Pulsar package - SR2->SR2 update: JEE package Linux 64-bit - R->SR2 update: CPP and JEE packages - SR1->SR2 update: RCP/RAP and Java packages - SR2->SR2 update: RCP/RAP package Given that this list covers most update scenarios and given that the download server statistics tell me that there were at least 916 requests in the last few days without new bug reports, I hope that it is safe if I decide to use the new repository. I will enable the Helios SR2 update of the EPP packages soon.
Great news. But i already download the full SR2 and used same workspace
When I did "Check for Updates" again today, I got an update for "Eclipse IDE for Java EE Developers 1.3.2.20110301-1807". I installed it, and the same thing happened; my eclipse.ini was deleted. Also, in "About Eclipse" the build ID still says "20110218-0911".
(In reply to comment #32) > When I did "Check for Updates" again today, I got an update for "Eclipse IDE > for Java EE Developers 1.3.2.20110301-1807". I installed it, and the same thing > happened; my eclipse.ini was deleted. Also, in "About Eclipse" the build ID > still says "20110218-0911". Jacob, I assume that's on a Mac? (I tried Windows, and (still) seems to work ok.) And were you updating from original Helios release? Or Helios SR1? I wonder if there could be some "stale mirrors" with old content still? Jacob, if you are able and willing to test this bad mirror hypothesis, you could add -Declipse.p2.mirrors=false to your vm arguments to avoid mirrors (for just this test). By about box build id (after update) does say Build id: 20110301-1815. If it is a mirror problem ... then we'd have to figure out why that is a problem. Shouldn't be "offered" to p2, if not up-to-date. Markus,
Yep, this is on a Mac. I'm upgrading from SR2, actually -- does your suggested test still apply?
I haven't given this too much thought, but this seems to be the 'expected' behaviour. When you upgraded from SR1 to SR2 the name was changed from eclipse to Eclipse (in the metadata) and this caused the original problem you reported. Now when you upgrade from SR2 to SR2a, the name is changed again (from Eclipse to eclipse) causing the same problem. The (hopefully typical) case will be from SR1 to SR2a in which the name now remains the same. Pascal, does that explanation make sense to you?
No, doesn't apply. I think Ian is spot on. No joy from SR2 to SR2a. :( Is that from a fresh SR2, from download site? Did we get those upgraded too? Markus, and others ... did we get those updated appropriate? Do we need to? Or, is Jacob just suffering from being a trail blazer? :)
No, that was from the "check for updates" update to SR2 that caused me to report this bug.
(In reply to comment #37) > No, that was from the "check for updates" update to SR2 that caused me to > report this bug. It is still not clear to me what you were updating to SR2a. Was it (a) an update of a fresh download of the JEE SR2 package or (b) did you try another update of your broken SR1->SR2 update to this SR2a. If it was (b) then it is not expected to work (or: I never tested this scenario). A self-healing update from a broken Mac OSX SR2 to SR2a was out of scope. (In reply to comment #36) > Is that from a fresh SR2, from download site? Did we get those upgraded too? If you download any of the SR2 packages and search for updates, you will get a very small update of the package feature IU but not an update of anything else. Unfortunately this was necessary since I didn't want to modify the existing EPP build just for this fix (would have been too risky). The goal was to have a working update scenario from <=SR1 to SR2 and not from broken SR2 updates to SR2a.
> It is still not clear to me what you were updating to SR2a. Was it > (a) an update of a fresh download of the JEE SR2 package or > (b) did you try another update of your broken SR1->SR2 update to this SR2a. It was B. After performing the steps in the original bug report, and manually restoring the eclipse.ini, I updated again to SR2a. So I guess it's expected that it would break again.
Assigning to default because it shouldn't be assigned to me any more. The problem had been fixed by a workaround at that time, but it seems that this workaround doesn't work any more. See bug 390756 which seems to be similar (or a duplicate) to this one.
(In reply to comment #7) > Sometimes I just hate macs... > > File previousLauncherIni = launcherData.getPreviousLauncherIni(); > if (previousLauncherIni != null && > !previousLauncherIni.equals(launcherConfigFile)) > previousLauncherIni.delete(); > launcherData.setLauncherConfigLocation(launcherConfigFile); > > /Users/Pascal/Eclipse.ini is equal to /Users/Pascal/eclipse.ini.... To be clear, the problem is that on make Eclipse.ini is not equal to eclipse.ini, but if you delete one, it will delete either. The underlying file system is case sensitive but Mac pretends it isn't. In core.filesystem we use a workaround like this to test for equal files: if (LocalFileSystem.MACOSX) return file.getPath().toLowerCase().equals(otherFile.getPath().toLowerCase()); return file.equals(otherFile);
(In reply to comment #41) > To be clear, the problem is that on make ... Typo, this should read, "the problem is that on Mac ..."
And for completeness: import org.eclipse.osgi.service.environment.Constants; static final boolean MACOSX = System.getProperty("osgi.os", "").equals(Constants.OS_MACOSX);
(In reply to comment #43) > And for completeness:... Thanks John, I've opened bug#390967 to discuss improving case sensitive files on MacOS. I think we should close this bug since this problem was fixed in Helios SR2.
I see the same behavior in Eclipse Indigo after a SR1 update.
(In reply to comment #45) > I see the same behavior in Eclipse Indigo after a SR1 update. It's the first time that this is being reported for an Indigo package and I checked that the Indigo (R, SR1, SR2) metadata is correct (i.e. setLauncherName(name:eclipse)). When you try (were trying) to update... * what versions are shown in your about dialog before the update and * what versions are offered during the update? Especially if you click on the 'Installation Details' button in the About dialog.
This just happened to me as well, and with the previous update. I am running Juno SR1. As far as I can tell, the update this time was from Eclipse IDE for Java Developers 1.5.1.20120920-0737 EPP Java Package 1.5.1.20120920-0737 to Eclipse IDE for Java Developers 1.5.1.20121004-1506 EPP Java Package 1.5.1.20121004-1506 The About dialog shows this after the update: Version: Juno Service Release 1 Build id: 20121004-1855
This first happend to me when updating from Indigo JEE to Indigo SR1 JEE package: from Eclipse IDE for Java EE Developers 1.5.0.20120614-1633 to Eclipse IDE for Java EE Developers 1.5.1.20120917-1257 I also have Subclipse, Groovy, Gradle, and Grails plugins installed. When I checked for updates again a few days later, I found some (can't remember which one, the installation history doesn't show any differences in the first level, so it must have been on some deeper level. Unfortunately, there's no "expand all" button, so I skipped manually opening hundreds of features). After it happend to me for the first time, I manually restored eclipse.ini from the original Indigo download, after the second time from the SR1 download.
Just happened again for me...I had Juno SR1: Eclipse IDE for Java EE Developers 1.5.1.20120917-1257 and updated to this: Eclipse IDE for Java EE Developers 1.5.1.20121004-1506 and the eclipse.ini file was deleted.
(In reply to comment #49) > Just happened again for me...I had Juno SR1: > Eclipse IDE for Java EE Developers 1.5.1.20120917-1257 > and updated to this: > Eclipse IDE for Java EE Developers 1.5.1.20121004-1506 > and the eclipse.ini file was deleted. Jacob, How did you get 1.5.1.20120917-1257? Did you update (from the June release), or did you download it?
I probably should have posted that to bug 390756. To be honest, I don't remember whether I downloaded or updated to Juno SR1. Is there any way to tell?
(In reply to comment #51) > I don't remember whether I downloaded or updated to Juno SR1. Is there any > way to tell? One way is to open 'Help' > 'Installation Details' > 'Installation History'. Another way is to look into the plugins/ directory for the versions of the EPP branding plug-in: plugins/org.eclipse.epp.package.* But this method works only until p2 removes / garbage collects the old unnecessary bundles.
Responding in bug 390756.
(In reply to comment #45) > I see the same behavior in Eclipse Indigo after a SR1 update. Sorry, I meant Eclipse Juno....
I have seen the java.lang.OutOfMemoryError: PermGen space due to a eclipse.ini deleted by Eclipse upgrades several times when upgrading from Eclipse Juno 4.2 to 4.2 SR1, and again today when I picked up the EPP Java Package update from 1.5.1.20120920-0737 to 1.5.1.20121004-1506. This has occurred on several Mac OS X 10.8 64-bit machines. eclipse.buildId=M20120914-1800 java.version=1.6.0_35 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -product org.eclipse.epp.package.java.product -keyring /Users/davids/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.java.product -keyring /Users/XXX/.eclipse_keyring -showlocation
(In reply to comment #55) > I have seen the java.lang.OutOfMemoryError: PermGen space due to a > eclipse.ini deleted by Eclipse upgrades several times when upgrading from > Eclipse Juno 4.2 to 4.2 SR1, and again today when I picked up the EPP Java > Package update from 1.5.1.20120920-0737 to 1.5.1.20121004-1506. This has > occurred on several Mac OS X 10.8 64-bit machines. I'm also using Eclipse Juno 4.2 on a Mac OS X 10.8 64-bit machine and the same problem occured for me during the last two updates. There is no clear error "your eclipse.ini is missing" so it's a bit annoying for a normal user like me to find out what the problem is.
So what is _this_ bug for, exactly? I think the most recent problem (with Juno) was fixed in bug 390756. Is there more work to do in p2 for the future? Or, should we "transform" this bug as a request to provide some better log message like "Warning: no eclipse.ini was found". Naturally, eclipse.ini is not always required by everyone, so it can't be described as an "ERROR" nor just "stop" (might almost be an "Info" message, more than a "warning"), but there are similar cases we handle; such as if someone specifies -debug (but no .options file) that "warning: we did not find a .options file at <default location> ... not that one has to to use a "debug .options file", but, that's often the intent so (I'm assuming) someone thought it best to provide a little extra info. Or, is this bug for something else, and a new bug open for improved diagnostic message?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
