Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 106211

Summary: [plan item] Improve target support
Product: [Eclipse Project] PDE Reporter: Mike Wilson <Mike_Wilson>
Component: UIAssignee: PDE-UI-Inbox <pde-ui-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P4 CC: baumanbr, gunnar, jeem, khorowit, mpcarl, pombredanne, sja.eclipse, tjwatson
Version: 3.1Keywords: plan
Target Milestone: 3.2 M5   
Hardware: All   
OS: All   
Whiteboard:

Description Mike Wilson CLA 2005-08-05 12:55:31 EDT
PDE manages a model of the target Eclipse for which you are developing. Targets may be complex and 
diverse, and switching targets or launch configurations can be expensive. PDE should be extended to 
support named targets and automatically track changes to the workspace. [PDE, Core]
Comment 1 Wassim Melhem CLA 2005-08-18 08:53:16 EDT
*** Bug 80163 has been marked as a duplicate of this bug. ***
Comment 2 Brian Bauman CLA 2005-09-12 19:22:57 EDT
Possible requirements for Named Targets:

It would be advantageous to users if they could compile their code against a 
subset of the full target platform.  This would allow the user to develop 
projects for a variety of platforms and versions in one workspace.  These 
subsets should consist of possibly selecting features, plug-ins, fragments, and 
other subsets to include for the project’s development.  These subsets should 
be usable for build path management and for use with launches and product 
configurations.

The ability to programmatically add named sets for a user would simplify the 
process for a user, as Named Targets could be created for the user by ISV 
developed plug-ins.  One option may be via extension point.  The ability to 
define these in the target platform and have them created when the target 
platform was loaded may also prove useful.  

We should also have the ability to allow users to define Named Targets through 
a UI.  Users would be able to composed their Named Targets from scratch, or add 
to existing Named Targets.

It might be helpful to a user to be able to sort OS independent bundles vs. OS 
dependent bundles/fragments.  Thereby allowing the user a quick way to create a 
subset based on an OS/architecture.  This is just an option and may not be 
valuable enough to implement.

These Named Targets could also be valuable to a user in the launch dialog.  
They could select one of the Named Targets in the launcher to quickly select a 
set of plug-ins/fragments/features.  This way they could quickly launch the 
plug-ins/fragments/features to correctly simulate their environment.  This 
could be useful in pre-populating the plug-ins/fragments/features on the plug-
ins page of the launcher. 

A user may want to create a named target from an existing names target, so the 
implementation would need to support inheritance of named sets.  For example:

NamedTargetA:
	- org.eclipse.osgi
	- org.eclipse.swt

NamedTargetB:
	- NamedTargetA
	- org.eclipse.jface

One implementation might be using features to define Named Targets.  These 
features would contain features/plug-ins/fragments.  The feature defining the 
Named Target could have metadata in the feature telling PDE that it is defining 
a Named Target.  During the parsing and loading of the plug-ins in the Target 
Platform, the PDE would load this Named Target. 

Named Targets should be configurable through the PDE preference page.  This 
page should allow the user to select and create new Named Targets.  The launch 
dialog should have the capability to select and launch the plug-ins in a Named 
Target.

Named Targets might also be able to warn the user if they reference a class or 
package from a plug-in that is not in the current Named Target.  This would 
ensure the user will not unknowingly write code referencing classes that won’t 
be available in the runtime.
Comment 3 Wassim Melhem CLA 2006-02-13 06:50:36 EST
Here is how we addressed this item:

1. Target Definition

A target definition is a .target file that can be created via File > New > Other... > Plug-in Development > Target Definition.
Three options when creating a .target file:
  i.  blank file
  ii. a target based on the current target platform settings
  iii. a target based on an existing target definition.

The .target file opens in a form-based Target Editor that lets you specify all aspects of a target:
1. name
2. location 
3. additional locations without the need for links.
4. Content (in terms of plugins or features or both)
5. target environment (ws, os, arch, nl)
6. JRE (default or by name or by Execution Environment)
7. Program/VM launching arguments associated with this target
8. Implicit dependencies when using this target.  This option is useful when running a target that requires certain plug-ins that are not explicitly listed in a plugin's manifest file.

On the Target Platform preference page, you can browse the workspace for .target files and load them

We also introduced a new org.eclipse.pde.core.targets extension point to allow products to ship with pre-canned targets.

The target combo box on the Target Platform preference page is pre-populated with all registered org.eclipse.pde.core.targets extension.

The org.eclipse.pde.core.targets extension take a unique ID, a translatable name, a translatable description, and a path to the .target file that describes the target.

Finally, on the Target Platform preference page, you can preview a target before loading it.  The Preview displays the content of the target in a form-based tabbed window.