- 1 Launch Configuration Template Use Cases
- 1.1 Design Decisions
- 1.2 Create a new template
- 1.3 Create a template from an existing configuration
- 1.4 Create a configuration based on a specific template
- 1.5 Update all configurations made from a template
- 1.6 Rename a template
- 1.7 Delete a template
- 1.8 Disconnect a configuration from its template
- 1.9 Associate a configuration with an existing template
- 2 Launch Configuration Template User Interface
- 3 Launch Configuration Template API
- 4 Default Launch Configuration Settings (Workspace, Project preferences)
Launch Configuration Template Use Cases
The following use cases are intended to be used a starting point for launch configuration template design and integration into the debug platform.
Templates behave like cookie cutters. A configuration can be based on a template, which seeds attributes in the configuration with the settings specified in the template. Once a configuration has been created, the user can override any initial settings from the template. The user can also modify the template and push changes out to the configurations based on it. A configuration maintains a backpointer to its template, but is a complete standalone congifuration than can be launched, exported, shared, etc.
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.
Thus, 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" 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).
Create a new template
To creating a template use the "New" drop down button in the LCD tree viewer toolbar, and select "Template".
Create a template from an existing configuration
Select the configuration you would like to make into a template, and then select "New > Template" from the context menu or drop down tool bar action. A template is created with the contents of the selected configuration. And the existing configuration becomes a child of the template.
When a configuration, based on a template, is selected and the use chooses to make it a template, a new template will appear at the root (2nd level of the tree), based on the configuration. The action creates a new template based on the selected configuration.
Create a configuration based on a specific template
Select the template in the LCD and press the "New" button. This will create a new configuration associated with the selected template, initialized with attributes from the template.
Alternatively, double-clicking on an existing template will create a configuration based on that template.
Update all configurations made from a template
From time to time, attributes in a template will be modified. When the "Propogate..." button is pressed (in place of run/debug buttons) the user will be prompted to update all children configurations (and have the option to "do not ask again"). The dialog will allow for selective update (check box selection) to children configurations.
Rename a template
Launch configurations keep track of which template (if any) they are based on. When a template is renamed in the LCD, all configurations made from that template will be updated to refer to the renamed template. This is much like a refactoring.
Delete a template
When a template is deleted in the LCD, users will be prompted to delete all children assocaited with the template. When children are not deleted, they are moved up a level in the tree (re-parented).
Disconnect a configuration from its template
Drag & drop allows a user to re-parent a configuration to a different template or to no template (dropping on configuration type node).
Could have "Move..." action with a list of templates or root node (no template).
Associate a configuration with an existing template
A configuration can be associated with an existing template using drag & drop (dropping on the template). When this happens, the user will be prompted to apply the template settings to the freshly dropped configuration (with a "do not ask again" option).
Launch Configuration Template User Interface
Display template relationships and provide convenience actions
The launch configuration editing area will be enhanced as follows:
- The "Name:" label will be changed to "Template Name:" when editing/displaying a template.
The LCD tree viewer will be enhanced with the following:
- The "New" button will be enhanced into a drop down to allow a new "Configuration" or "Template" to be created. By default (i.e. just pressing the button), a confiugration will be created.
- Nest configurations by template - i.e. all configurations based on a template will be displayed as children of that template.
- Double-clicking a template in the tree will create a new configration based on that template
- Drag & drop to allow configurations to be re-parented under a different template (or disasscoiated with its template by dragging to the top level).
Launch Configuration Template API
API will added to the following interfaces to support launch configuration templates
- Get all templates of this type
- Create a new working copy based on a given template
- Set whether a configuration is a template
- Set the template a configuration is based on (backpointer)
- Copy attributes from a configuration into the working copy
- Return whether a configuration is a template
- Get the template a configuration is based on (backpointer, may be null)
- Get all configurations a template is associated with
- A new method to validate templates. The default implementation will not validate templates (as they will usually have sparse/incomplete information that would be invalid). Clients can provide an implementation of the new method to perform template validation as needed.
- The launchConfigurationTypeImages extension will be enhanced to allow a custom image to be provided for templates. When no image is provided the platform could use a default template image (or we could experiment with disabled images).
Default Launch Configuration Settings (Workspace, Project preferences)
Related to launch configuration templates, are default workspace and project settings for launch configurations. Users can acheive features similar to default workspace/project settings by managing templates, but the SDK could also offer explicit support for this.
A user may want to define default settings for certain launch aspects. For example, a default JRE or VM arguments to use for all Java applications. Although this could be achieved with a template, one could imagine having default settings that could be applied to newly created launch configurations. Default settings work like preferences - they are used to override settings in specific launch configurations, but the launch configurations themselves contain no backpointer/reference to the settings (unlike a configuration based on a template, which keeps track of which template it was based on). The user can maintain a hierarchy of templates orthoganal to default settings. Newly created templates would obtain default settings the same way a configuration would.
Define default launch settings for a workspace
Default workspace settings can be defined for each launch configuration type available in the workspace. A toggle button would be present in the LCD to set a configuration as default for the workspace. The label of the workspace default configration will be bolded and have a "(workspace default)" qualifier.
Initializing a configuration based on workspace default settings
Workspace default settings should initialize newly created configurations when created in the LCD or by invoking a launch shortcut.
Issues with project/resource based default settings
It might be useful to have project or resource based default settings. Hoewver, this is problematic as the API used to create a configuration does not currently specify a resource context (and thus the platform cannot infer which template to base a configuration on).
One could imagine using resource mappings, but this delays the template assocaition until the time when a new working copy is saved (i.e. for the first time only), its resource mapping will be used to determine what settings (i.e. which scope - project or workspace) should be used to initialize the working copy. Any default settings found, will be applied to the working copy. The platform cannot determine the proper scope to use until the configuration is saved, as when a configuration is created, a resource scope is not provided. As well, the scope may change while the working copy is being edited.