In Debian we have been experiencing problems with the simpleconfigurator, which I hope we can solve by improving the simpleconfigurator and its handling of read-only shared installs.
The situation:
In Debian (and Ubuntu) we distribute eclipse via our own package format using eclipse-build from LinuxTools. In our eclipse-platform package we ship the basic part of eclipse (e.g. without -jdt or -pde) and this contains a bundles.info. This contains information about all bundles eclipse depends on as well as the bundles we ship in eclipse-jdt and eclipse-pde (these two may or may not be installed on the system).
When the user starts eclipse for the first time, eclipse will generate a bundles.info file in his/her home directory inside ~/.eclipse/ somewhere. So far so good.
The problem:
If we (for whatever reason) need to upgrade an external bundle (say our lucene2 bundles), the bundles.info files are outdated. We can (from the distributing side) ensure that the system bundles.info always are in sync with the bundles installed on the system in the shared install, but we cannot update the bundles.info in the user's home directory.
The symptom is that all the user installed bundles are silently dropped and only the bundles provided in the system bundles.info are present. This seems to be confirmed by the code in SimpleConfiguratorImpl.java (line 103 in eclipse 3.6.2):
As you can probably imagine this is first of all very hard to debug and secondly suboptimal for us and our users.
My proposal is to extend the simpleconfigurator to handle this case by never storing system bundle info in the user bundles.info file and always load the bundles from the shared install's bundles.info.
Obviously, just naively doing that may break existing installs, so I am perfectly okay with us having to explicitly setting a property in the config.ini or use a variant of the bundles.info.
I understand that your time may be limited and you may have tasks with higher priority, so I am willing to assist with the changes (though my knowledge in this area is somewhat limited).
If this is implemented, we would like to backport it to our eclipse 3.7 (or 3.7.X) package, so it would be greatly appreciated if patches could be posted here.
Hi
In Debian we have been experiencing problems with the simpleconfigurator, which I hope we can solve by improving the simpleconfigurator and its handling of read-only shared installs.
The situation:
In Debian (and Ubuntu) we distribute eclipse via our own package format using eclipse-build from LinuxTools. In our eclipse-platform package we ship the basic part of eclipse (e.g. without -jdt or -pde) and this contains a bundles.info. This contains information about all bundles eclipse depends on as well as the bundles we ship in eclipse-jdt and eclipse-pde (these two may or may not be installed on the system).
When the user starts eclipse for the first time, eclipse will generate a bundles.info file in his/her home directory inside ~/.eclipse/ somewhere. So far so good.
The problem: torImpl. java (line 103 in eclipse 3.6.2):
If we (for whatever reason) need to upgrade an external bundle (say our lucene2 bundles), the bundles.info files are outdated. We can (from the distributing side) ensure that the system bundles.info always are in sync with the bundles installed on the system in the shared install, but we cannot update the bundles.info in the user's home directory.
The symptom is that all the user installed bundles are silently dropped and only the bundles provided in the system bundles.info are present. This seems to be confirmed by the code in SimpleConfigura
return (userBundles. containsAll( sharedBundles) ) ? userConfigURL : sharedConfigURL;
As you can probably imagine this is first of all very hard to debug and secondly suboptimal for us and our users.
My proposal is to extend the simpleconfigurator to handle this case by never storing system bundle info in the user bundles.info file and always load the bundles from the shared install's bundles.info.
Obviously, just naively doing that may break existing installs, so I am perfectly okay with us having to explicitly setting a property in the config.ini or use a variant of the bundles.info.
I understand that your time may be limited and you may have tasks with higher priority, so I am willing to assist with the changes (though my knowledge in this area is somewhat limited).
If this is implemented, we would like to backport it to our eclipse 3.7 (or 3.7.X) package, so it would be greatly appreciated if patches could be posted here.
Thanks for considering and your time,
~Niels