Community
Participate
Working Groups
build 2002-05-16 (test build) on WinXP IBM JRE 1.3.1 I tried to start the new build on my old workspace (from 2002-05-15) and it wouldn't start. I got the following message in my .log file. !STARTUP 5/16/02 9:03 PM Exception launching the Eclipse Platform: !STARTUP 5/16/02 9:03 PM java.lang.reflect.InvocationTargetException: java.lang.RuntimeException: Fatal Error: Unable to locate matching org.eclipse.core.runtime plugin at org.eclipse.core.internal.boot.PlatformConfiguration.locateDefaultPlugins (PlatformConfiguration.java:2048) at org.eclipse.core.internal.boot.PlatformConfiguration.<init> (PlatformConfiguration.java:845) at org.eclipse.core.internal.boot.PlatformConfiguration.startup (PlatformConfiguration.java:1264) at org.eclipse.core.internal.boot.InternalBootLoader.initialize (InternalBootLoader.java:511) at org.eclipse.core.internal.boot.InternalBootLoader.startup (InternalBootLoader.java:857) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:732) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:450) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:189) at org.eclipse.core.launcher.Main.run(Main.java:632) at org.eclipse.core.launcher.Main.main(Main.java:465)
Created attachment 861 [details] my .config directory zipped up.
*** Bug 16084 has been marked as a duplicate of this bug. ***
*** Bug 16108 has been marked as a duplicate of this bug. ***
I've got it in 20020517. Renaming the .config folder solves it. The .config is available upon request.
Rodrigo, please attach the contents of .config. I thought I knew what was happening but that theory did not pan out.
Created attachment 874 [details] config.zip
Looked at the ZIp, seems our thinking is right ...1630.xml points to file:C:/eclipse/runtime/20020515/eclipse the next history ..2356.xml points to file:C:/eclipse/runtime/20020517/eclipse/ Reconciliation considers it as a new site, thus disable all the found features... They ar eboth platform:/base as PlatformURL
*** Bug 16302 has been marked as a duplicate of this bug. ***
There are three basic scenarios that I can think of the fall info the category "reusing existing workspace with new build". [A] user installs a brand new eclipse in a new install location and creates/ modifies a shortcut that uses the new install and existing workspace. This is our typical self-hosting scenario, and is what exposed this defect. [B] user installs a brand new eclipse over top of an existing (prior version of) eclipse. We do not do this with build .zips, but a native installer may do this when applying service, possibly when doing minor version upgrade [C] user installs a brand new eclipse into the same install location as the previous version, but in the process also deteted the previous version. Some people may do this when self hosting (ie. delete the old drop, and unzip the new one in its place). Native installers may also do this, possibly when doing minor version upgrade, and probably always when doing major version upgrade. The end user can also trigger this by uninstalling the old version first, and then installing the new one into the same location. This defect is as a result of scenario [A]. To fix this the reconciler (on startup) needs to detect the fact that the install site referenced by platform:/base/ URL has in fact changed (the resolved old and new URLs differ). If this is the case, then force optimistic reconciliation regardless of what the reconciler was called with. We should reconcile optimistically across all install sites we know about (ie. should make the determination if we are in this situation at the start of the reconciliation process before any of the sites areactually processed). This fix handles the case where the new install is the same version, or different version of the platform. Scenario [B] should work with the current support. When started, we start running the older version of the platform, detect this, do reconcilliation (pessimistic because the is not "first use" scenario), force a restart that will notify the user that there are changes. If the user accepts the new changes, we configure the new features and restart (which will cause the updated platform to run). If the user declines the changes, we just continue with the older version. The user has the option to go into the update manager later and configure the new stuff. On single user platforms like Win the expectation is that the user would always accept the changes. On multi-user platforms, or shared LAN install, it is possible that a user defer applying the change that was made by the shared-install "administrator" to later. Scenario [C] needs to be detected in Main.java launcher. If we use the bootstrap information in platform.cfg to get the location of BootLoader, but the location is no longer valid (because it references the old version that is gone), we need to kick in the default search for boot instead of failing. If we find boot using the default search algorithm (generally will locate the latest version found in the install location) we would also force "first use" reconcilliation processing. This means the reconciler would be called on startup with "optimistic" as the setting. Optimistic reconciliation would apply to all sites we know about. Note, that if the user explicitly specified -boot on startup and it is bad, we will fail as today. So, [A] needs a fix in the reconciler, and [C] needs a fix in Main.java ..... both for F1
Scenario [A] Added method platformBaseChanged() is SiteReconciler. Tested the following Installed 0508 in C:\SDK 0508\ Installed 0515 + code from HEAD in C:\SDK 05015\ Start 0508 with -update -data c:\TEMP start 0515 with -debug -data c:\TEMP 0515 opens, the log shows !MESSAGE Install/Update WARNING:Platform URL found is different than the one previously saved. Reconcile optimistically:file:/C:/SDK 0515/eclipse/ : file:C:/SDK 0508/eclipse/ The reconciliation happened optimistically and the Workbench opened. [A] fixed.
Pass to Vlad for Scenario [C]
Changes for [C] released into HEAD (org.eclipse.platform, org.eclipse.core.boot).
This is still a problem with 2002-05-19. I am following scenerio [A].
OK, can you please attach .metata/.config directory and any .log I presume you are moving from 0515 to 0519
Created attachment 884 [details] log file
Created attachment 885 [details] config directory
I was moving from 05-17 to 05-19.
We did not contribute update core into 0519 so scenario [A] will still be broken. Will be in the 0520 evening build (not the regular nightly build, the 10pm build Jim said is being scheduled) and in the F1 build.
Scenerio [A] is ok in 2002-05-20. (moving from 2002-05-19)
Also verified with 0520. Closing.
