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
