[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] Update on shared install work



Early September, I was mentioning on this ML that Ericsson was sponsoring some work on shared install for Ericsson. After an initial start on a couple bugs (http://bugs.eclipse.org/249133 and http://bugs.eclipse.org/389667) , I have been sidetracked by some other work that you may hear about at EclipseCon (http://www.eclipsecon.org/2013/sessions/automating-consumption-eclipse-internal-use).


Now I’m back at the shared install problem and wanted to give you an update on the scope of the problems that will be resolved and the approach taken. I’m posting this here to the wider audience to ensure visibility of the progress, but please direct feedback / questions / ideas to bug http://bugs.eclipse.org/304132.


=-=- Recap of the problem =-=-=

When in a shared install setup the base changes, there are a number of bad problems:

- The user looses his plugins but he is not notified that this has happened.

- The configuration that he is running may be erroneous (e.g. fails to start)

- The user is not provided with a way to reinstall his plugins


=-=-= Overview of the solution =-=-=

Below is a plan in 4 phases that helps improve the situation. Each phase builds on the previous one, but each phase completed stands on its own. That said, to significantly improve the situation, it is recommended to do at least phases

1 and 2.


1) Detect changes and warn the user

This phase is focused on detecting that the base has changed, and let the user know that plugins have been uninstalled.


During the boot sequence of eclipse, we need to detect if key configuration files of eclipse have changed (config.ini, bundles.info). If there are changes, ignore the user level files, continue the boot sequence using the files from the base. Upon provisioning make sure these files are still ignored, so we don't read the old state.


The profile registry also needs to be altered in order to make sure the user is presented with the appropriate state when he does Help > About > Installed software, and so he can actually proceed with the re-installation.


Once the workbench is up, a dialog will notify the user that the install has been modified.


Additional notes:

- Files to worry about are config.ini and bundles.info. What happens if the config.ini file has not changed but bundles.info has? Do we want to do anything in particular?

- We need to make sure that the config.ini file is not updated even if it has not changed. (e.g. when the user has installed bundle, no new entries should have been added to config.ini).

- We may need a flag to make sure that this dialog does not causes problems during tests and such.



2) Migration dialog

This phase focuses on replacing the simple notification done in step 1, by a migration wizard that lets the user bring over from the previous install the software he needs.


The migration wizard automatically presents what the user had installed and let the user pick which plugins he wants to migrate. A good starting point for this dialog, if the import wizards that is already provided in p2.

When the wizard opens it should offer sensible defaults in terms of the enablement state of the IUs to migrate. For example the older version of the base should not be proposed, or IUs that may have been added to the base.


The migration should also allow the user to migrate the repositories that were in the previous install, and try to be selective to only include those that contain software that has been installed from those (for example if I only migrate eclemma I don't have to have the PMD repo).



3) Migration & update

This phases focuses on improving the migration wizard to allow the user to look for updates to the roots that he had in his previous install.



4) Migration during the boot sequence

While the phase 1 provides an opportunity to migrate once eclipse is up, this phase automatically performs the migration before the workbench is opened. In the way it hooks into the startup sequence, this is similar to the dropins. This should be a headless operation that only migrates what can be migrated, and then provides a report as to what could not be migrated. This last part could segway into letting the user look for updates for the entries that could not be migrated.

Given that this can be quite disruptive, it will be an opt-in option.