| Summary: | [plan item] Improve target support | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Mike Wilson <Mike_Wilson> |
| Component: | UI | Assignee: | 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.1 | Keywords: | plan |
| Target Milestone: | 3.2 M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Mike Wilson
*** Bug 80163 has been marked as a duplicate of this bug. *** 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. 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. |