Bugzilla – Full Text Bug Listing
| Summary: | [target] Target platform preferences should not be imported | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | John P. A. Verhaeg <jverhaeg> |
| Component: | UI | Assignee: | Darin Wright <darin.eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | curtis.windatt.public, darin.eclipse, mpcarl |
| Version: | 3.1 | Flags: | curtis.windatt.public:
review+
|
| Target Milestone: | 3.5 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
can you give me an example of how preferences were not kept? Keep in mind that the target platform location in the preferences behave in a unique way to accomodate self-hosting scenarios. That is, if target platform = host platform, and we are using the same workspace, if you launch an Eclipse located at (D:/Eclipse) on that workspace, the location on the pref page would appear as D:/Eclipse. If you launch an Eclipse located at C:/Eclipse on that same workspace, you would see the value as C:/Eclipse. This allows people to launch multiple instances of Eclipse on the same workspace and be able to work readily. In this scenario, we only save a boolean value that indicates target platform = host platform. If target platform != host platform, ie. you explicitly specified a different location, this value will of course be stored in the preferences. It's not the target platform value that's the problem; it's the selected plug- ins within the target platform. So, for instance, if you are running Eclipse 3.1, but have 2.1 plug-ins in your workspace, then the target platform would be pointed to a 2.1 Eclipse installation. If you additionally want the compiler to use some of the Eclipse 2.1 plug-ins that are in your workspace (not linked), and not in the installation folder, then you would deselect those plug-in projects in the target platform preferences panel. It's these selections (or rather deselections) that are not being saved in the preferences file. When trying this out in 3.5M5 preference import/export wasn't working perfectly for me. However, in 3.6 we may move away from storing the target platform information in the preferences (to support features like per-project target platforms). We will try to look at this again for 3.5, but if possible you should move towards using target definitions files to store and move around target information. All target platforms in 3.5M5 are backed by target definition files. We should use a PreferenceModifyListener to intercept preference import. When preferences are imported: * if the "active target handle" does not exist, we should not change the target platform * if the target handle being imported does exist, we should allow the settings to be updated (and run a set target platform operation if needed) * if the preferences being imported do not specify a target handle we should not change the target platform Darin, since you were looking into this, can you decide if you have time for this in 3.5? This bug is being hi-jacked a little. The original request was to properly export/import tagret platform settings. However, target platforms should not be shared this way anymore. They should be shared via target definition files. Target platform settings are now ignored when importing preferences (i.e. current settings remain intact). Added TargetPreferenceModifyListener and associated extension. Verified. |
The individual project selections in the "Preferences->Plug-in Development- >Target Platform" preference page are not being stored in exported preferences files.