Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox/p2/Location selection scenarios"
(→Select Bundle Pool on Install) |
(→Mac OS X layout) |
||
Line 16: | Line 16: | ||
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: | 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: | ||
− | * /Network/Library/''Equinox/Bundles'' - shared across multiple computers, probably read-only | + | * /Network/Library/Application Support/''Equinox/Bundles'' - shared across multiple computers, probably read-only |
− | * /Library/''Equinox/Bundles'' - shared across multiple users on the current computer, probably read-only | + | * /Library/Application Support/''Equinox/Bundles'' - shared across multiple users on the current computer, probably read-only |
− | * ~/Library/''Equinox/Bundles'' - accessible by the current user, probably read-write | + | * ~/Library/Application Support/''Equinox/Bundles'' - accessible by the current user, probably read-write |
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. | 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 | + | 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 [http://developer.apple.com/DOCUMENTATION/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html Where to put files] and [http://developer.apple.com/DOCUMENTATION/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html Library directory] on Apple's site for further info. | ||
[[Category:Equinox p2]] | [[Category:Equinox p2]] |
Revision as of 14:41, 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 Bundle Pool on Install
<Note: This needs to be recast as a scenario. Why would they be unhappy? What are they expecting when setting this location?>
It should be possible to select the target bundle pool when installing plug-ins in Eclipse. The functionality can be compared to selecting an extension location when installing plug-ins prior to Equinox p2.
It is mainly motivated by user control to help driving user satisfaction. If you take control away from a user, it will make him/her unhappy. Therefore, a user should be able to keep control over the layout/organization of software on his computer. Additionally, the concept of extension locations has been well adopted within Eclipse. For example, PDE allows to compose plug-ins in wizards, dialogs and editors by grouping plug-ins based on their install locations.
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:
- /Network/Library/Application Support/Equinox/Bundles - shared across multiple computers, probably read-only
- /Library/Application Support/Equinox/Bundles - shared across multiple users on the current computer, probably read-only
- ~/Library/Application Support/Equinox/Bundles - accessible by the current user, probably read-write
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.