[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] [prov] Shared install filesystem layout
|
>where such things
What does such refer to, plugins or preferences?
"Alex Blewitt"
<alex.blewitt@gma
il.com> To
"Andrew Overholt"
08/10/2007 06:34 <overholt@xxxxxxxxxx>, "Equinox
PM development mailing list"
<equinox-dev@xxxxxxxxxxx>
cc
Pascal Rapicault/Ottawa/IBM@IBMCA,
equinox-dev-bounces@xxxxxxxxxxx
Subject
Re: [equinox-dev] [prov] Shared
install filesystem layout
I should also throw into the mix ... on Macs, there's
/Library/Application Support/Eclipse and ~/Library/Application
Support/Eclipse as standard places where such things could go and be
considered to be on the search path for bundles (I think I suggested
the idea of a BUNDLEPATH somewhere in one of my bug reports). So
whilst having a logical separation of ideas is good, let's think about
how they might work for other OSes as well :-)
Alex.
On 10/08/07, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
> 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.
>
