Community
Participate
Working Groups
With our native installer, we are laying down our base features. These features also have install handlers to complete their work. According to the update team, on the first time we run, if we use the -initialize switch, the install handlers should all be run with the completeConfigure method be called. This is not happenning. When we run with -initialize, our features install handlers are not being run
Sorry if we misled you. We probably meant the first time eclipse runs (when no workspace exists before)
Created attachment 1774 [details] Custom Install Handler Test File
STEPS TO RECREATE: Use attachment (com.ibm.ive.test_1.0.0.jar) This is what happens when you try the -initialize option: 1. Unzip the com.ibm.ive.test_1.0.0.jar to a com.ibm.ive.test_1.0.0 folder inside the eclipse\features folder of a fresh eclipse 2.0 base. 2. Run eclipse.exe -initialize. A workspace will be created. 3. Notice that there is NOT a com.ibm.ive.personalconfig-install.log in the root of the eclipse\features folder. This shows that the -initialize option did not call the custom install handler of the test feature. This how you can manually force eclipse to install a custom install handler feature (as an alternative to performing a update via the Update Manager); 1. Unzip the com.ibm.ive.test_1.0.0.jar to a com.ibm.ive.test_1.0.0 folder 2. Launch a fresh copy of Eclipse 2.0 (i.e. no workspace has been created yet). 3. Shut down eclipse 4. Place the com.ibm.ive.test_1.0.0 folder inside the eclipse\features folder. 5. Launch eclipse 6. Notice that you will have a dialog asking for you to accept pending changes. Choose to accept. 7. Let eclipse restart. 8. Notice that there is a com.ibm.ive.personalconfig-install.log in the root of the eclipse\features folder. This means that the custom install handler code was run.
Checked 2.0 code. We do not call the install handler during a reconciliation where the new feature is found and enabled (optimistic). the code is changed in 2.0.1 (will check with 2.0.1) the new code will call the install handler if a new feature is found and the reconciliationis optimistic. The new code does not call the install handler during an enable/disable of an already existing feature.
need to address for 2.0.1
Was already fixed in 2.0.1. Verified based on brooke comments: "I downloaded the 2.0.1 integration build of eclipse off www.eclipse.org. The exact file was: eclipse-SDK-20020724-win32.zip. When I put my custom install handler feature in the features folder and ran eclipse -initalize, I noticed the feature was properly installed and the custom install handler was initialized. So I can see that 2.0.1 solves our problem but in 2.0.0 this does not work. -Brooke- "
Tim, can you guys also verify that fix for bug 20686 (which as a side-effect fixed this problem) gives you expected behavior for Revert operations? I would expect (am guessing here) your customers are likely to save different configurations representing the various target environments, and then use revert to switch back-and-forth. So want to make sure you verify this is working as expected (we have tested this but there is nothing like real usage test).
Please let us know if we can close it for 2.0.1
Based of the latest WSWB drop of I20020821, I have verified that the troubles with the -initialize option have now gone away. As for the revert command, this looks good as well. I can revert to past configurations and then forward again and do not notice any errors or corruption in the workspace. If I should be looking at something more specific, let me know.
Confirmed as fixed.
