Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Equinox p2 Shared Install

Summary of Needs

For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server. In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.

Beyond performing reconciliation, when a reconciliation can not be made, the user will need to be presented with the list of software that is no longer compatible after reconciliation similar to what happens when you upgrade to a new major version of FireFox. When the user is presented with the list of software that is no longer compatible, the option could then be presented to automatically search for newer versions of that software.

Proposed Solutions Discussed

Custom Configurator with Intelligence

One option would be to provide a custom configurator that replaces the standard one used in the provisioning work. This configurator could be structured to check the shared profile source and then compare against the current list of bundles. Since the configurator deals at the bundle level, and the reconciliation needs to happen at the IU-level, this would require a lot of mapping and complex logic.

Reconciler on Launch

Another option is to have a simple configurator start the runtime with only enough plugins to run the reconcilation logic. This would work with IUs and see if reconciliation is needed between the shared profile and the user's instantiation of this profile. The benefit of this solution is that the reconciler can leverage the provisioning agent, but there is the potential for impact to the Eclipse startup time (needs investigation to understand impact).

Simple Configurator with optional Reconciler

A third option is to have a simple configurator that knows about a shared bundle list and the user's bundle list. This configurator could then check if the shared bundle list has changed, and if it has, only use the shared list. The reconciler could then be launched on startup to allow updating the user's addons to the profile. This approach would partially work but not necessarily handle some cases such as those required by Maya where checking if the shared profile has changed is more complex.

Current Approach

For a first implementation, we have decided to attempt the Reconciler on Launch approach. Our thought is to have an Activator start that performs the reconciliation running on a bare-bones OSGi runtime. The reconciler would check for differences and update the user's profile as needed. Finally it would either continue to load the extra bundles into the current runtime or if some base software has changed, potentially reload the base OSGi runtime and then launch the desired application.

To begin, we are creating two bundles:

  • org.eclipse.equinox.prov.shared - contains the activator and code to look up the shared profile
  • org.eclipse.equinox.prov.reconciler - contains the reconciler to resolve the differences between two profiles

In addition, the shared bundle will have an extension point allowing an ISharedProfileProvider to be specified. In the case of Maya this would have an implementation that coordinates with the central server while the shared linux install would have a version that retrieves the shared profile that might have been installed via a packaging mechanism.

To enable the reconciliation to take place, there may be additional properties stored in config.ini or alternate configuration file that are used by the activator, profile provider, and reconciler.

Back to the top