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 <[EMAIL PROTECTED]> 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. > _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
