Hallo Dorian,
* Dorian Birsan wrote:
So the update can be scheduled to happen automatically through the OS's
automatic program scheduling mechanism.
No, this is through the update manager built-in support for automatic
updates: [...]
I'm not sure from what context you come, but when you have a unix
system, you will have eclipse installed in a common folder and all
users of this maschine can use it. This senario isn't very good
supported by eclipse right now (debians packages fix that, I hope...).
Anyway, this requires, that only the root user has the right to write
an change eclipse programm files (-> features/plugins). No sane user
should login into X being root, so no X is present, so no eclipse
without headless operation.
eclipse as a typical linux programm looks something like this:
* package manager managed core
-> /usr/share/eclipse
* system wide extentions, installed by root and not the package manager
-> /usr/local/share/eclipse
* per user configuration in
-> $HOME/.eclipse
and extention in
-> $HOME/.eclipse/eclipse
The first two 'sites' should not be updateable by the users
updatemanager, only the third plugin/feature location should be
accessed by the update manager in eclipse.
In the debian packages, this is currently achieved by
* patching PlatformConfiguration to setup /usr/share/eclipse as
readonly *in all cases*.
* setting a 'links' file with 'path=r /usr/local/share', using
"internal API" to ensure that this location is also readonly.
* adding a patch to PlatfromConfiguration, so that the user can use a
'addsite' option, which works like a 'links' file, only on a per
runtime basis.
* per User configuarion (of the using window system, data dir and
additional plugin locations) is in $HOME/.eclipse/eclipsrc and will
be used by a starter script, which repalces the binary starter
(which is only used to display the pslash screen).
This basicly disables update manager, as in the 2.x stream, there is a
bug, where you can't see any 'linked in' site and so only see
/usr/share/eclipse (which is readonly and not writeable anyway), but
not $HOME/.eclispe/eclipse
To sum it up: eclipse is a very windows centric application and does
not fit at all into the *ix 'view of the world'.
I hope that the RCP will not suffer from this. On unix I would expect
that the core RPC plugins can be shared by several apps, without one
app seeing others apps config/appearance/contributions. I hope that's
possible by the current implementation.
Thanks for reading this rant :) I've filed some bugs about the above
shorctomings. One includes the 'plugin in $HOME' patch, one is about
not using the normal unix 'highlight and paste' clipboard (eclipse is
the *only* app, where I *have to* use strg+c and strg+v, removing one
of the most loved look&feel issues of *ix...). The RCP issues were
raised in the bugzilla of that changes.
Jan
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev