Community
Participate
Working Groups
The Java EE EPP for Mars has received some bad feedback during testing, especially around configuration of WTP runtime's More details here: http://www.eclipse.org/forums/index.php/t/1067556/ In summary - The recorder can be turned off an on, but the preferences are always loaded from the "saved" global cache, and could throw away recently saved local preferences. This is a bad usability issue that customer will surely hit, and I feel the fix is so small and safe that it justifies a late respin of the EPP packages. Suggested fix: one line change to plugin_customization.ini file: org.eclipse.oomph.setup.ui/enable.preference.recorder=false
I've created Gerrit change https://git.eclipse.org/r/50398 Please test the results of the Gerrit verification build and vote in Gerrit.
Hey Markus - Can you create another patch? At first I didn't realize the fix was against the reporter EPP, not JEE.
Thanks for noticing it! I've reverted the first change with commit 1640f55e928e5e5b9769b8d6e766031ea44b9b42 and created a new change in Gerrit: https://git.eclipse.org/r/50403
+1 for doing this so oomph won't by default be cause of subtle bugs/preferences resets.
Test build looks great - Thanks Markus!
Do I get this right: This problem shows up with JEE but not with the other packages, since the Granularity of the "Server Runtimes" Preference is such that a single Preference Slot saved by Oomph overrides everything ? And in case each Server Runtime were backed by a separate Preference Key that Oomph may or may not "overwrite" from the user's shared Preferences, things would be good ?
(In reply to Martin Oberhuber from comment #6) > This problem shows up with JEE but not with the other packages, since the > Granularity of the "Server Runtimes" Preference is such that a single > Preference Slot saved by Oomph overrides everything ? Yes, this happens for any type of preference that's represented a large XML blob of many things. > And in case each Server Runtime were backed by a separate Preference Key > that Oomph may or may not "overwrite" from the user's shared Preferences, > things would be good ? Yes, if there were individual preferences per server with keys containing a server's URL all would be good.
afaik there are quite a lot of places where preferences are used to contain "bulk" of data; basically anything that is a list of things. Not sure how to handle that better but seems like we need to make oomph smarter or allow it to be extended by plugins to handle these situations ?
(In reply to Max Rydahl Andersen from comment #8) > afaik there are quite a lot of places where preferences are used to contain > "bulk" of data; basically anything that is a list of things. Yes. > Not sure how to handle that better but seems like we need to make oomph > smarter or allow it to be extended by plugins to handle these situations ? Yes, we plan to revisit the recording control after Mars.
(In reply to Martin Oberhuber from comment #6) > This problem shows up with JEE but not with the other packages, It was also discovered in the Testers package. See bug 470561.
We've now fixed the problem that compound XML preferences can be overwritten by Oomph and the fix will be in our Mars.1 RC1 build, see bug 475139. We also plan to have an interesting new feature in Oomph for Mars.1 that will enable users to synchronize their perferences between their Eclipse Bugzilla account and multiple local machines. Of course this new feature depends on our Preference Recorder to capture their local preference changes. So the following question becomes even more important now: Are you ready to remove the disablement property from your plugin_customization.ini files?
what if the content is not xml but json or some comma separated list ?
