Community
Participate
Working Groups
When a workspace that has been created by 2.0.3, is opened using 2.0.2 that happens to have the same installation directory, problems occur. In the case of a productized version of Eclipse, the effect is that the main product feature (from the product based on 2.0.2) is disabled. The workarounds available are (each of which cause a full reconciliation): 1) to make sure 2 install directories are different 2) remove the .metadata/.config directory from the workspace 3) change the id of the product feature A testcase has been provided to Christophe (not included here since it contains WebSphere Studio code).
Bug issue: Eclipse 2.0.2 reconciler disable features scenarios: a) The user installs WSAD 5.0.0. The user installs WSAD 5.0.0.2. The user upgrade to WSADie 5.0.0 a bis) The user installs WSSD 5.0.0. The user installs WSSD 5.0.0.2. The user upgrade to WSAD 5.0.0 b) The user installs WSAD 5.0.0. The user installs WSAD 5.0.0.2. The user uninstall WSAD 5.0.0.2 and install WSAD 5.0.0 c) The user installs WSAD 5.0.0. The user installs WSAD 5.0.0.2. the user copies its workspace on another station where WSAD 5.0.0/WSADie 5.0.0/WSSD 5.0.0 is installed why ? When the eclipse startup is triggered, it checks if the path to the platform has changed, if the primary feature is the same and if the version of boot.jar has changed from the previous execution. If one of them changed, an OPTIMISTIC reconciliation is triggered. An optimistic reconciliation enables all new found features. If a feature is not new (meaning we knew about it before), the reconciler will set the feature to the same state (enable/disable) as before. In a WSAD 5.0.0.2 workspace, WSAD feature 5.0.0 and 5.0.0.1 are disable. Feature 5.0.0.2 is enabled. when starting WSAD 5.0.0 against a WSAD 5.0.0.2 workspace, the reconciler will discover that an optimistic reconciliation is needed. It will then realize that the WSAD features 5.0.0 and 5.0.0.1 were considered disabled in the last state and thus honor the previous state. what are the consequences ? The platform will start without branding. Most of the tools will not be enabled. The user will see errors regarding disabled plugins. No user data should be affected. How to solve it if the user is in this state ? delete the .config directly under your workspace metadata. The same situation will occur if the user goes back and forth between a 2.0.3 product and a 2.0.2.1 product. How can we prevent it? 1) we can patch the 2.0.2 reconciler to enable all features, not only the new one. 2) we can have the 2.0.3 reconciler save a state that the 2.0.2 reconciler cannot read. 1) pros: simple fix, cons: will need to tell user to apply the fix to all 5.0.0 install 2) pros: no need to patch any 2.0.2.1/5.0.0 products cons: not so trivial fix, need a lot of testing 1) what is the fix: Change the code so if an old site is found, treat it as if is was a new site. upgrade, downgrade, switch back and forth, and change workspace will trigger full reconciliation (as if there was no state) history reverting will not be supported by the UI 2) The fix is for the reconciler to save its state in a different file that the 2.0.2 reconciler. (localSite.xml config<number>.xml). The 2.0.2 reconciler will not find the localSite.xml nor the 2.0.3 specific history states. It will find the 2.0.2 state in the directory and use the latest 2.0.2 state for reconciling. We need to ensure 2.0.3 reconciler supports 2.0.2 state AND 2.0.3 state. We need to test: upgrade, downgrade, switch back and forth, history reverting, change workspace, 2bis) we can have a parallel state for 2.0.3 that 2.0.2 doesn't understand, so if user switch back and forth they will use the state of the 'platform'. So 2.0.3 will only know about LocalSite_v2.xml file.
Proposed solution. Have 2.0.2 reconcile completely when it connects to a 2.0.3 workspace. Have 2.0.3 reconcile completely when it connects to a 2.0.2 workspace. Have 2.0.3 reconcile completely when it connects to a 2.0.2/2.0.3 workspace. In both cases, the first run against a 'never seen before' workspace will trigger the reconciler. The 2.0.3 reconciler will read the 2.0.2 update manage state and transform it into a 2.0.3 update manager state. It will delete the 2.0.2 manager state. Upon other startup, the 2.0.3 update core will read the 2.0.3 update manager state. When a 2.0.2 reconciler will attempt to read a 2.0.2 workspace, it will not be bale to find any of its state (as the files have changed) and thus behave as if .metadata/.config was deleted. It will read all the features,consider them all new, and reconcile properly. Upon startup, the 2.0.2 update core will only know about the 2.0.2 update manager state. Even if there are 2.0.3 files, the 2.0.2 update will not read them. When you start a 2.0.3 update manager again against a 2.0.2/2.0.3 state The 2.0.3 reconciler will read the 2.0.2/2.0.3 update manage state and transform it into a 2.0.3 update manager state. It will recognize there is a 2.0.2 state and delete the 2.0.2 update manager state. Upon other startup, the 2.0.3 update core will read the 2.0.3 update manager state. forward compatibility. Versions higher than 2.0.3 will reconcile in full when the platform, primary feature, boot version change. We will not attempt to preserve the customer state anymore. If the user upgrade/downgrade, some of the features you disabled, will be re-enabled as is the .metadata/.config was deleted. Action Taken: implemented, Tested with platform, all integration unit tests passes Action Plan: pass to steve, test regression
My test is the following: Install eclipse 2.0.2.1 from a zip Install root 1.0.0 from a zip Startup (root 1.0.0 and eclipse 2.0.2.1 are enabled) Install 2.0.3 and root 1.0.1 in the same directory Startup (full reconciliation will occur, make sure Eclipse 2.0.3 and root 1.0.1 are enabled) Check the workspace now contains .metadata/.config/platform.cfg.metadata/SiteLocalState.xml not .metadata/.config/platform.cfg.metadata/SiteLocal.xml (no state in name) Delete eclipse (2.0.2.1 and 2.0.3), delete Root (1.0.0, 1.0.1) Install Eclipse 2.0.2.1 and Root 1.0.0 in the same directory Start eclipsemake sure Root 1.0.0 and eclipse 2.0.2.1 are enabled
To allow the code to execute all the time if needed, we have to add a 'cookie verification' during startup. This verification will check if a pre-2.0.3 Update manager state exists. If it does, the cleaning part of the code will delete the LocalSite.xml and any Config<>.xml. This will delete pre-203 and post-203 Update manager state. in 2.0.3 code, we should put the code for verification and deletion in PlatformConfiguration in 2.1 code, we should add some cookie verification in Main, as well as another argument for the executable. PlatformConfiguration will catch the argument and execute the cleaning part. This will also allow user or 3rd party to execute eclipse -reset if they want to delete the content of the directory. We will also add an API SiteManager.reset() for UI or other plugin to use.
Action taken: fix release in 2.0.3 and 2.1 stream Action Plan: close
close
