Community
Participate
Working Groups
Steps: 1) Create a new target definition in local metadata 2) Set it as the target platform 3) Close Eclipse 4) Delete the backing target definition in pde.core metadata 5) Open Eclipse, open target preference page Result: Nothing is selected, but there is still a target platform. Once we remove the old target platform preference page we will have to handle this case where something happens to the fiel backing the current target platform. We should probably log an exception and create a new target platform based on the current settings. This should happen for workspace files as well. If we add support to open external files and set them as the target platform this problem will get worse (bug 264056).
The solution Darin and I are proposing for this is as follows: When the backing file for a non-active definition is deleted the definition no longer shows up on the preference page (this works now). When the backing file for the active definition is deleted explicitly (hitting the remove button on the pref page), we will delete the file and set the target platform to null. Note that we may prompt to ask the user if they really want to delete a workspace file. When the backing file for the active definition is unaccessible when the preference page opens, we will put up a warning message and offer a link to create a local definition based on the current platform settings (this option is already available in the Add... wizard but is not obvious to the user). The new definition will be added to the page and set as active. If the user hits OK on the page without setting an active definition we will prompt to ask the user what to do. The user will have to choose one of three things "Yes" throw away the current settings and set the target platform to null "No" keep the current target platform, the user will be prompted again if they return to the page "Cancel" return to the page. It isn't clear what should happen if the apply button is pressed instead of OK (controls have already been drawn).
Why should we allow "null" as active target. If user does not choose any target as active, then the "default" one should get marked active automatically. This is because thats the effect anyway. Currently, When no target is marked active and user creates a new Launch Config of "Eclipse Application" type, there the target plugins are visible and they come from default one only. This creates a gap in the story. If no target is active, there the target plugins are come from and why.
If the user explicitly deletes their target definition on the preference page, it makes more sense to set the target platform to null then reset to the default (and put something back on the page). If the LoadTargetOperation runs with null, it should clear out the target platform preferences (so new configs won't have target plug-ins). If there are no definitions set as active, but the LoadTargetOperation has not been run, then there will be plug-ins in the configs that appear to come from no where. I agree that this is not good, but we should only reach this point if the user has not visited the pref page (since the definition file was deleted). We still need to warn the user that something has gone wrong when they open the page and their definition is unavailable. I think that every case will be covered appropriately. 1) No definitions ever (new workspace) - create a default definition 2) No definitions (3.3 workspace) - create a default definition and current definition 3) User goes to page and removes all definitions - null platform 4) User deletes the definition file that is active - target platform doesn't change, if the user goes to the page we let them know the file was deleted and how they can create one using the existing settings. (4) is the only new piece.
Created attachment 131850 [details] Patch Page marked with error message if the target definition file of active target can not be location. The label below describes what can be done next.
The patch doesn't apply cleanly it seems.
Created attachment 131912 [details] Updated Patch Looks like updates due to other patches in same files screwed this one up. The patch won't work for external files without fix delivered for bug #264056.
Reworked the patch so that the warning is more clearly shown to the user and is removed when the user sets a target as active. Also found and fixed an NPE caused by previous changes to the UI. Thanks Ankur.
