Re: [equinox-dev] [prov] Shared install filesystem layout

["Alex Blewitt" <alex.blewitt@xxxxxxxxx>]

I'd personally be against the platform-specific fragments in a
.../lib/... dir. Quite often, if you want to ship something, then
having it mountable in one place (e.g. /usr/share/eclipse) is easier
than having it in several places. In any case, the Jars themselves are
platform portable; it's just that some are active on one OS and others
are active on another OS. I don't see that there's any benefit in
splitting the definition here, just because there's some kinds of
difference in fragments. Ideally, you'd want to be able to end up with
a distribution that could work on multiple platforms anyway, with the
only difference being the launcher.

FWIW the 'lib' is usually separate from the 'share', because the
'share' is mounted noexec, whereas the 'lib' is. That's unnecessary on
an Eclipse install, though, because the fragments are stored as Jars.
(it might make a difference to where the .dlls or .sos are extracted
*to* however, but that's a separate issue.)

One of the big things I think Eclipse misses out on is the ability to
distinguish 'cache' state from 'preference' state in the .metadata
(i.e. **/*.prefs vs others). It would be really useful to have the
concepts of 'etc' (for preferences/configuration), 'var' (for cache
state that's generally useful to keep around but can be thrown away if
necessary), 'tmp' (for temporary files that can be wiped on every
restart, or when the user feels like it). If you had those
distinctions, it would make migrating from one workspace to another
easy; you'd just copy the 'etc' component part. There's a secondary
problem as to how you'd determine programmatically which they were
from the prefrerences state API, and whether you'd have
'org.eclipse.foo/etc' or 'etc/org.eclipse.foo' as the storage layout
(the latter being easier to bulk move/copy).

A couple of other thoughts in the mix; do you want to have a single
'bundles' directory, or have multiple locations? And inside the
'bundles' directory, do you have a single flat list or structure it
more like Maven? I think that instead of a very long flat list, having
eclipse/emf/.... eclipse/jdt/... eclipse/rcp/... etc. would be a good
way of (a) breaking up the list, and (b) communicating some kind of
reference as to what the plugins do. Coming up with a suitable naming
convention might be tricky, but you could always dot-separate the
bundles by name e.g
bundles/org/eclipse/equinox/org.eclipse.equinox.ds_1.2.3.jar.

BTW a rename from 'plugins' to 'bundles' would be good if there's big
changes afoot anyway :-)

Alex.