Difference between revisions of "Equinox/p2/Location selection scenarios"

Revision as of 15:12, 2 January 2009

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. Later on he might want to share these folder between different runtime and development configurations. Another user might want to organize plug-ins in a way he is used to (maybe to align it better with the OS).

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.