Magellan/Design/Eclipse Configuration Management

Eclipse Configuration Management

Summary

The Eclipse Configuration Management feature is meant to simplify the delivery a collection of Eclipse plugins with a base Eclipse platform. The intent is to simplify the installation of Eclipse as well as the selection and installation of features often desired by developers.

These plugins may include (in order of preference):

• Eclipse add-on plugins that are not included with the base Eclipse distribution (CDT, WTP, etc.)
• Third-party plugins
• Plugins created as a part of this project

We will continue to provide RPMs for the base Eclipse platform for Linux installations. The pattern deployment will be implemented as technology that simplifies the selection, installation, and management of additional plugins. Media installations as well as the Eclipse update site mechanism will be supported, as well as potentially RPM in the future. This work is a component of the Magellan Guadalquivir Phase.

Features

For the Guadalquivir Phase, we plan to include the following:

Future components could include:

• Eclipse PHP Tooling (Not released yet)
• Eclipse JavaServer Faces Tools (Not released yet)
• Eclipse Data Tools Platform (Not released yet)
• Eclipse Device Software Development Platform (Not released yet)
• Eclipse SOA Tools Platform (Not released yet)

Delivery Proposal

1. Make key features of Eclipse available via RPM. This would include the platform, IDE, and JDT. This is actually available today and will continue.
2. Contribute an Eclipse Plugin or make modifications to simplify the selection and installation of plugins as pattern deployments rather than specific features.
3. Modify the Eclipse Update mechanism (or write a plugin to this effect) so that plugins can be installed in home directories and that this takes precedence over system installations.
4. Preinstall Eclipse Update Sites for all of the aforementioned plugins that do not become a part of the "key features" discussed earlier. This would include plugins identified in this document as well as future plugins.

Additional Considerations

We need to work with the Eclipse foundation on our packaging and distribution efforts. The major issue we face is in obtaining the correct and complete source code snapshot for a component in order to build it in a closed system. We need to standardize on a way for a component to provide a source code snapshot as well as to be built. The building is less of an issue; it can be figured out.

Two other interrelated issues are a) the dependence of each package on the SDK in order to be built, and b) version variations. All the components of the distribution need to be of the same version, so distribution versions are essentially in lock-step with each other. For example, if the Eclipse SDK offers a stable release called x.y.z, a) how does one go about checking out x.y.z and not some more current, albeit less stable version, and b) how does one go about selecting the additional components of the other features that correspond with the x.y.z Eclipse stable release, and c) how does one ensure that the additional component is also at a stable release point?

Perhaps the Eclipse foundation would consider offering RPM format as an alternative built format.

Other Plugins?

Are there other plugins that you think should be included in this feature? Add them to the list, or if the one you want is already there, you can second someone else's proposal. A proposal can be "seconded" as many times as people want to show support for it, but don't second it more than once. There is a document history - we can tell if you are cheating.

List of Proposed Additional Plugins

Technical Implementation

Eclipse Update Feature Enhancements

The Eclipse Update feature will require the following modifications:

1. When a user creates a new update site, Eclipse should ask the user, "Install this feature for everyone or just for you?"
2. If the user responds to install for themselves only:
   1. Eclipse should install the feature in a default location for extensions.
   2. Eclipse needs to create a new extension location on disk, if necessary, and maintain this for the user.
   3. The user needs to be able to specify an alternative location. These all need to be managed automatically.
3. If the user responds to install for everyone:
   1. Eclipse should check to see whether the user has sufficient permission to complete the installation prior to starting.

Managed Extension Locations

The extension location(s) shall be located by default underneath the directory .eclipse directory in a subdirectory named .extensions in the user's home directory.

The contents of this directory are as follows:

• It must contain a directory named eclipse.
• It must contain a subdirectory named features in the eclipse directory.
• It must contain a subdirectory named plugins in the eclipse directory.
• It must contain a file named .eclipseextension in the eclipse directory.

The .eclipseextension file follows the java.io.Properties format and should look like this:

name=Acme Visual Tools Pro
id=com.example.acme.acmefeature
version=1.0.0

Every time a new plugin is installed to this location from the update mechanism, this file should automatically be updated by Eclipse.