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/Location selection scenarios

< Equinox‎ | p2
Revision as of 15:20, 2 January 2009 by Gunnar.wagenknecht.org (Talk | contribs) (Select location on install)

This page tries to collect scenarios and use cases for controlling the various locations used by p2. This includes managing the location initial location of a profile, p2's data area, shared locations, the location into which additional function is installed and the relationship to the bundle pool etc.

Each details a scenario and is followed by one or more approaches. In some cases the scenario is not currently supported and a bug report may be listed.

Install

Select location on install

It should be possible to select the target location when installing plug-ins from within Eclipse. The functionality can be compared to selecting an extension location when installing plug-ins in the old Update Manager.

User Happiness

Remember the keynote at EclipseCon 2005? If you take control away from a user, it will make him/her unhappy. Some users are used to organize content on their systems the way they want to organize it. There are plenty reasons for this. For example, a user might want to place plug-ins from a single project into a separate folder - one folder containing the ECF, another containing Webtools. Later on he might want to share different folders between different runtime and development configurations.

Another user might want to organize plug-ins in a way he is used to. Maybe he just wants to align it better with the OS. But it is also possible that he simply wants to keep things separated (eg. don't mix experimental plug-ins from project XYZ with stable plug-ins from project ABC). Yet another option is to share some plug-ins between different runtime instances (eg. an image viewer plug-in and Subversion tooling for every instance but PDT only in one).

Therefore, a user should be able to keep control over the layout/organization of software on his computer.

Usability

Another advantage are several usability improvements within Eclipse. The concept of extension locations has been well adopted within Eclipse. For example, PDE allows to select plug-ins in wizards, dialogs and editors by grouping them based on their install locations. This improves the usability in PDE when working with multiple Eclipse based applications/projects in multiple workspaces. For example, one can easily compose a target runtime simply by selecting the different plug-in locations - in one workspace it's Equinox + ECF in another it's the Platform + Webtools.

Mac OS X layout

The current Eclipse.app is pretty badly laid out for Mac OS X systems, as is the location of the bundles. Macs have several hierarchies of places where things can be expected to be placed/read from, in the following order:

  • ~/Library/Application Support/Equinox/Bundles - accessible by the current user, probably read-write
  • /Library/Application Support/Equinox/Bundles - shared across multiple users on the current computer, probably read-only
  • /Network/Library/Application Support/Equinox/Bundles - shared across multiple computers, probably read-only

Although it should be possible to define these as 'dropins', there doesn't seem to be any easy/obvious way to have multiple such directories.

There's a bunch of secondary issues for the Mac bundle, such as that everything it needs should be inside the Eclipse.app rather than dropped outside it; and logs shouldn't be written inside, but rather outside in ~/Library/Logs. P2 is somewhat inflexible and assumes a wrietable location for the application isnatll folder when extracting e.g. configuration.ini. Even if that directory is writable (e.g. running with admin priviledges) it should defer to some per-user location instead. (The common argument - that we want to install multiple different versions of Eclipse - is almost completely unnecessary when running as a 'normal' user, but rather something that Eclipse developers might do more frequently.)

For a 'default' Eclipse install, it might make sense to have Eclipse.app/Contents/Resources/Equinox/Bundles/ as the location for key bundles, like ECF, OSGi.jar etc.

See Where to put files and Library directory on Apple's site for further info.

Back to the top