Community
Participate
Working Groups
Steps to reproduce: 1. Open new workspace 2. Change preference X 3. Export ALL preferences using Preferences export wizard. Note: Only changed preferences are exported. Those with default values not. 4. Change preference Y 5. Import ALL preferences exported in step 3. Note: Preference Y is still changed. Some users may expect that exporting and importing ALL preferences they will get the same preferences state as before export. But it's not the case. It would be useful to have an option to reset all preferences in a workspace prior to import, to make sure that all old settings won't interfere with new settings.
This sounds similar to bug 267392.
Changing Version tag to something more believable. Note that this is not a statement about when the enhancement request will be addressed (the Target Milestone field is used for that); the Version tag should be set to the version of Eclipse you were using when you saw the need for the enhancement.
Created attachment 140964 [details] Initial work The code is terrible but seems to work. *Constructive criticism is welcome.* If user wants to clear preferences, all InstanceScope and ConfigurationScope are removed from the tree (so only DefaultScope will be used).
Created attachment 140965 [details] mylyn/context/zip
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
(In reply to comment #3) > If user wants to clear preferences, all InstanceScope and ConfigurationScope > are removed from the tree (so only DefaultScope will be used). Deleting data from two major preferences area does not strike me as a safe solution. It causes problems even for a base clean Eclipse install; more importantly, those areas are open to all Eclipse plugins to use. Consider this simple example that shows a problem with this approach: with the patch applied; open Windows -> Preferences -> General -> Network Connections. It works fine. Now export and re-import preferences using the new option. Open the Network Connections page again. Note the error message: "The currently displayed page contains invalid values." and the underlying exception: java.lang.IllegalStateException: Preference node "org.eclipse.core.net" has been removed. Depending on the state of Eclipse you might see some other exceptions or problems in processing as plugins don't expect their preferences to be changed by other players. The patch could be made a bit safer by adding restart after new preferences have been imported. However, this approach assumes that all preferences stored in those areas a safe to throw away, which, generally, is not correct. Using the Network Connections again as an example, what happens if I had proxy settings stored there? Suddenly part of Eclipse stops working and I need to open a ticket with IT support who are the only people who know those magic IP numbers. Deleting preference files is OK as a workaround when things go into a bad state. If we were to provide a UI trigger for it, it should be a separate action with clear warnings and ability to see what's being deleted. (Better yet, how about having a "clean up" Eclipse startup mode. Say, if user presses "Shift" during Eclipse startup, launcher asks if you want to go into cleanup mode that, depending on user selection, adds "-clean" flag, clears preferences, shows debug information on bundles that failed to starts, and so on.)
Thanks for feedback Oleg.The exception in core.net is unacceptable, but it is hard to say right now why it happens. It may be an issue with core.net itself. But this is really a stopper for the patch. The main problem is that not all preferences are exported, and therefore you get inconsistent settings after importing them (a mix of old and new preferences). If you want to import all preferences and reset yours, than you should be aware/predict that your proxy settings will be gone (and eventually replaced with new ones!). Will it be safe to package such a patch into an ANT task? It is rather common case to launch Eclipse in headless mode to build something?.
(In reply to comment #7) > The main problem is that not all preferences are exported, and therefore you > get inconsistent settings after importing them (a mix of old and new > preferences). Yes, I agree. And in a perfect world your patch would work fine. However, plugins tend to make assumptions. In the case of the exception above, the core.net stores a preference node. The API for the preferences says that it can throw an exception if the node has been deleted; however, nobody checks for those exceptions as they simply do not happen. After all, who but core.net would want to delete its preferences node? :-) I can think about few assumptions that plugin authors make that will be broken in this approach: - nobody deletes / modifies my preferences but me - I can rely on preferences as a persistent storage - subset: if I have a one-time process (such as migration from previous Eclipse version), I can store its results in Preferences While those assumptions are not supported by APIs, they almost always work. Introducing code that breaks such assumptions is sometimes necessary, but we try really hard to avoid it. > Will it be safe to package such a patch into an ANT task? It is rather common > case to launch Eclipse in headless mode to build something?. I don't think that it will make any difference. If you have a workflow for which this is a showstopper, then you probably can produce a small plugin with the "overwrite preferences wizard" using your code above (+ add a strong suggestion to restart Eclipse after preferences have been cleaned; + add a clear warning that all Preferences data will be deleted). For the Eclipse SDK, the "initial work" patch seems like we would trade one set of problems for another. I think that proper solution would have to go deeper into Preferences export/import process.
*** Bug 267392 has been marked as a duplicate of this bug. ***
Hi, is there any update on this issue? Thanks.
Andrew, I am afraid this bug cannot be fixed correctly in 3.x stream. Any attempt of fixing this will break existing plug-ins due to reasons explained in comment 8. Oleg, is this bug a good candidate for e4?
(In reply to comment #11) > Oleg, is this bug a good candidate for e4? This is actually a hard question :-). Below is my opinion only. The really good candidate for e4 would be to combine our multitude of persistance mechanisms (preferences, extension registry, IMemento's, etc.) into one. That would be *great* e4 candidate. (While using known issues, like this bug, as design constraints.) That, of course, will only happen if we get somebody to commit enough time. I'd love to do it but I won't have nearly enough time to do it. If anoybody is really interested ( = ready to commit some serious chunk of time to this) I'll be very happy to work with you. Now, back to reality :-). E4 is targeted to be API-level backward compatible. What that means exactly is subject to interpretation, but if solution to this bug involves breaking API changes, it will have to be some Preferences2 mechanism, while keeping original Preferences for backward compatibility. In this particular case it is even worse than that as Preferences specification is part of the OSGi spec which, practically speaking, we can't change. So even non breaking changes woudl have to go into Preferences2. That, of course, would not help existing plugins until most of the Eclipse universe migrates to Preferences2. So, back to my first point: long-term best approach would be to look at the existing mechanisms and combine them into one using things we learned.
(In reply to comment #11) > Andrew, I am afraid this bug cannot be fixed correctly in 3.x stream. Any > attempt of fixing this will break existing plug-ins due to reasons explained in > comment 8. Then is there a recommended/documented workaround on achieving the desired behavior? (i.e. getting back the same preference state that was exported)
I have a group of 4 students which could do part of this work as their long-term assignment. They have basic Eclipse knowledge, and properly mentored, should be able to code this functionality if provided with requirements. Oleg, would you be interested in that kind of cooperation? If yes, I can try to think of preferences API which should serve as requirements, and post it here. We should have requirements before the end of March.
(In reply to comment #14) > I have a group of 4 students which could do part of this work as their > long-term assignment. Cool, thats interesting. Timing is somewhat off with Eclipse 3.6 and e4 1.0 work. Depending on how much assistance is needed, it might be better to see if we can schedule this for late summer or autumn. I'll send you e-mail with more details.
I disagree with the suggested approach. Instead of deleting upon import, we'd better also export the default preference values on export.
There are numerous bug reports about not exporting the default values causing the import to fail, if it contains default values and the user has set different values. An easy workaround would be if the removeNode method of the RootPreferences inherited by EclipsePreferences was public. You may then remove the users 'instance' node and import preferences afterwards. This way you can control if an import shall override user's settings. Another option is to provide this setting as an option to the import operation of the IPreferenceService that could remove the node internally. Removing the 'instance' does not yield any problems at it is lazily being reconstructed on access.
