Community
Participate
Working Groups
I picked the abstract title specifically to complement bug 76854. Of the surface it appears related to bug 76854, but think maybe the originator of that bug is making a different complaint. I realize the target *should* be exported during export (or, at least, user given the option to do so), but, its the fact that its exported with "all" selected, and then imported with "all" selected that causes me greif. In fact, its one of the things that limits my use of importing/exporting preferences, merely for "usability" reasons you might say. The scenerio is this. I routinely work with workspaces that have different targets. Some targets are 3.2 based, some are 3.1 based, etc. and to complicate things, some with certain "pre-reqs" installed, some with different combinations of "pre-reqs". In otherwords, the target is pretty important. So, if I change some font, some style, my list of "installed JRE's" etc., I'd like to make sure those same preferences are applied no matter which workspace I am operating on. But, if I "export all" from one workspace and then "import all" from another workspace, it typically "messes up" my target setting. If I'm wide awake, I can remember to turn off auto-build, do the "import all", then go fix my target workspace (or, confirm still ok), and then go back and turn on auto-build again. This is the step I often forget and seems I should not have to do. Note: if improvements were made in "global preferences" (dev. env. specific) were improved, as mentioned in bug 121902 and bug 70683, then this issue would be smaller. But, until there is some notion of prefernces specific to development environement, the work-around for that limitation is to frequently export-all and import-all, and this unwanted change of PDE target is an undesired side-effect.
David, I am not sure what you want happening on the PDE side. The whole Import/Export preferences is done at a Platform preferences level. If you want the ability to filter out some preferences from the export operation, you should open an enhancement request against that component. Am I missing something here?
I wrote too much didnt' I :) But, you are right on. The ability to filter out PDE targets on export and import would improve the situation. I still would consider it a bug, however, since I think the scenerio I describe is common (for us "downstream" teams) and often causes my target to unexpectedly change, and if I'm not paying attention, auto builds to complete with thousands of errors, requiring me to "clean", and wasting my time. Thanks for considering.
Moving to Runtime, since clients have no control over what preferences are exported. Should they introduce such filtering concept and should PDE be required to do anything as a result, we will be happy to comply.
I'm pretty sure that the UI does the preference exporting. DJ can confirm and move if needed. However, two observations, - does the new named target support help you here? That is, the target definitions are now in files that you can version manage and share with your friends. You just have to pick the target to use... - The export preferences wizard allows users to pick export all or select from a set of prefs. Its not clear how the list of three (in my setup) is defined but perhaps there could be one for PDE targets added (if that still makes sense after answering the previous question) Adding Wassim to the CC. You don't get off that easy.
I'm not sure about the named target support (I assume that's "target profile"?) Using a recent I-build I couldn't really figure out how to use -- looks like a subset of plugins? But didn't see workspace connection? And didn't see how to create? (Sounds interesting though ... a quick search of bugzilla showed no matches on "named target" or "target profile" ... pointers welcome). I suspect, though, named targets would compound the problem, unless you are saying they are simply never imported or exported, and the way of sharing them between workspaces would the the same as sharing them between team members. If so, that might prevent the "unintended change" problem I am discussing (but doesn't sound especially easy to use, across workspaces, that is -- I'm sure my team would not really be interested in all the goofy targets I use :) . I think I've found an analogy in another prefernces ... if my tiny tests are accurate. If I export "installed JRES" (with one of them as usual set as the "default to use in the workspace to build and test" via the checkbox on the prefernce page. Now, I can import those "installed JREs" to another workspace, but the current "default" is not changed. To me, this is similar to PDE targets, and to change the default on import would have similar bad consequences, with the way I set things up for development. It would suit me to export/import the list of PDE target locations (but guess that's an MRU list?) but to not change the actual current setting that is being used as the current one for the workspace. Granted, that may add a step for some who do want and expect that default to change ... but, I dont' actually see how that would ever be that useful, from my own patterns of use. BTW, I think Wassim's remark about no way to "exclude only one thing" from import export is correct, in general, and I've opened bug 125634 to help seperate that out. (But, think this PDE target problem deserves its own bug for now, since that's really the only thing I've ever found I've really wanted to exclude).
Named targets or target profiles are not relevant to this discussion as they are not preferences and do not get exported/imported. The problem here is simple (although I'm not sure the solution is going to be simple ;-) David wants to export all his preferences, with the exception of a few. These few happen to be related the Target Platform preferences. But that is just subjective and arbitrary. It could have been some Team or JREs preferences. Incidentally, I can point at another bug report (bug 76854) where people were fearing that their Target Platform preferences were NOT being exported. So the solution is to have a general mechanism at the UI level in the Preferences Export wizard where people can exclude the subset of preferences they want to exclude. Granularity of this inclusion/exclusion remains of course an open question.
This exclusion thing already exists. Its called IPreferenceFilter and that's why you get those 3 options by default when you go to export.
I've added a preference transfer using xml markup for the Target Platform settings however I can't find a way to use it to exclude the Target Platform settings from a preferences export. On the preferences export page there are two options: - Export all - Choose specific preferences to export It seems like there is only an inclusion option, we can either export all preferences or choose sets based on filters. How would one go about excluding a set of preferences from an export? (Selecting all but the "excluded filter" does not work since the resulting file does not contain any of the base platform preferences, only the selected filters.)
Some background: As part of the preference work we added 2 things: 1. preference filters 2. preference modify listeners 1. Preference Filters This is the xml mark-up that you see in the team.cvs.ui (CVS Repos), debug.ui (Installed JREs), and ui (Keys) plug-ins. This gives you the option to export only those preferences. So in the export dialog you have 2 choices: export everything or export only preferences related to certain function (cvs, jres, keys) In the old preference pages, besides the global import/export buttons, some teams had their own import/export buttons on their pages. So the above functionality was created in an effort to remove these extra buttons. 2. Preference Modify Listeners One other problem that we wanted to solve was the migration problem. Say you store preferences in a certain format (or with particular key names or whatever) and then you want to change that format, what do you do? For this, we created Preference Modify listeners. When you import prefs from disk, we read the tree into a temporary tree. Then before we apply the temp tree to the workspace, we call the registered listeners and they get a chance to modify the tree (and their pref format) before it is applied. Clients register modify listeners via runtime's preference extension point. ------------ So back to the original problem.... What I would do is: - ignore the preference filter mechanism (available in the ui ext pt) - all pde k/v pairs are still exported during an "export all" - create a preference modify listener that removes the appropriate key/value pairs when you do an import - if you wanted to be smart about it, you could probably do some checking to see if the paths were valid on import before removing them from the tree. I think an interesting feature request would be to add a pre-export callback to the preference modify listener. Then PDE could register one of these and remove any key/value pairs they wanted from the resulting exported file.
Thanks DJ for the analysis. for this particular issue, really the best solution is to have a mechanism at the Preferences Export wizard level to exclude preferences. Other alternatives are unattractive as they would lead to confusion on the part of the user and magic by PDE. Some want the target platform prefs exported, others don't. This should be handled at the user level, and not under-the-covers by PDE. Moving to Platform/UI as they own the preferences export wizard.
*** Bug 126312 has been marked as a duplicate of this bug. ***
Choosing a set to ignore is no more work than choosing a set to include. What is a better idea in my opinion is that we identify the preferenceTransfers that need to be implemented and log bugs for them.
