[platform-debug-dev] Launch Templates

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

While working on the user interface for launch templates, I stumbled 
across the problem described below. I've updated the WIKI (
http://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates#Design_Decisions) 
with this description. Any input would be appreciated. Basically, we need 
to decide if it is worthwhile moving ahead with the template 
implementation with this limitation.

Launch configurations are relatively simple attribute/value data 
structures. However, a launch configuration can use the absence of an 
attribute to indicate important data. For example, when the JRE attribute 
is not present for Java Application launch configurations, it indicates 
that the project (or workspace) default JRE should be used (depending on 
whether the configuration is associated with a project). This imposes a 
limitation on template implementation: simply copying attributes from a 
template to a configuration does not work for template application - as 
this does not cause unspecified attributes to be removed. 

For example, when a configuration specifies a specific JRE and a template 
specifies a default JRE (null), copying attributes will result in the 
specific JRE setting to remain in the configuration. For this reason it is 
important to persist "null" and "removed" values in configuration 
templates. This adds to the complexity of templates - as templates will 
often be incomplete. For example, a template would not often contain a 
main type name to launch - that whould usually be specified by individual 
configurations. So, if the template contained a null or empty main type 
name, we would not want this to cause the main type name in configurations 
to be wiped out. 

For these reasons, it is important that templates contain only the 
relevant (sub)set of attributes that they define, and that null/removed 
values are also persisted in the template. This also imposes restrictions 
in the user interface implementation. If all launch tabs are present for a 
template, all attributes will be present in that template - and 
effectively override all settings its children configurations. To solve 
this problem, a subset of tabs could be allowed for templates - and the 
user should decide which tabs are going to be present in their template. 
It also means that the effectiveness of templates depends on the existing 
set of attributes grouped on each tab, as each tab will be applied in its 
entirety to its children configurations. (The platform has no way of 
associating attributes with launch tab controls, so this is the finest 
granularity it can offer with existing APIs).

Darin