PDE Usage Scenarios

The following set of scenarios are designed to assist Eclipse user community explore and test the Plug-in Development Environment (PDE). Not all the scenarios are sequential but doing S1 and A1 scenarios first ensures that the basic functionality is correct.

If you find a problem with the scenario step, open a Bugzilla defect against component PDE/UI. Include the build number (e.g. RC1, RC2 etc.). Always prefix the description with the step number as in:

B7.5: Debugger does not stop at the second point

Setup

Scenario A: Basic plug-in activities in a simple self-hosting mode

In this scenario, the assumption is that there is an installation of a full Eclipse-based product. A small to medium-scale (value-add) ISV wants to add a relatively small number of plug-ins to the product. The final plug-in complement should be everything that is already in the product plus new plug-ins. Product plug-ins will be referenced from the outside, while the new plug-ins will be in the development time workspace. Although not prohibited, the assumption is that user's projects are not shared.

A1. Preparation for work

A2. Creating a new plug-in project.

Note: The first set of scenarios walk you through the plug-in development lifecycle manually. Newly added feature called 'extension templates' provides for very fast results using pre-packaged templates. If you want to have a very short 'speed to glass' starting with a clean install, jump to the scenario A12.

A3. Examining plug-in manifest editor pages

A4. Adding an action set

A5. Testing the newly added action set

A6. Refining the action set

A7. Debugging action set code

A8. Creating a new extension point

The following is an example of the extension point usage:
<p>
<pre>
   <extension point="com.example.xyz.parsers">
      <parser
         id="com.example.xyz.parser1"
         name="Sample Parser 1"
         class="com.example.xyz.SampleParser1">
      </parser>
   </extension>
</pre>
</p>
Note: XML Schema editor makes no guarantee that white space will be preserved in text that appears in Description field because it will be moved to an HTML file as-is, and HTML will not respect white space either. For any special formatting, HTML tags should be used and not tabs or white space. An exception to this rule is 'preformatted' text that is marked using <pre> tag. PDE will preserve white space between <pre> and </pre> tags so that the code examples end up looking correct when final HTML documentation is produced.

A9. Using the new extension point

A10. Unresolved and cyclical plug-in references

A11. Tracing Control

A12. Creating new plug-ins using plug-in templates

This scenario uses newly introduced plug-in templates to generate initial plug-in contents. The templates also serve double duty of providing initial extension contents for well-known extensions.

This scenario is most likely to be exercised with a fresh workspace (new install). If you spent some time testing PDE before this, exit Eclipse and start by pointing at a new workspace using "-data <workspace>" command line option.

A13. Adding new extensions using extension templates

This scenario shows how to add new extensions incrementally using templates. You can start with any plug-in.

A14. Manifest editor editing support

This is a free-form scenario. The goal is to test clipboard and undo/redo support in manifest editor form pages. Each non-source page in the manifest editor fully supports cut/copy/paste and undo/redo operations. In addition, object property changes through Properties view are also under Undo/Redo control. 

Scenario B: Advanced self-hosting

The second set of scenarios is designed to test binary project self-hosting. In this set-up, external plug-ins that serve as a development target are brought into the workspace by using the import wizard. The assumption is that you have already completed the 'A' scenarios and that everything works well. In binary self-hosting mode, plug-in references will be modeled as project references, but everything else should (and must) work the same and product the same results.

It is recommended to finish scenarios 'A' (at least to the point where you have a plug-in that compiles and runs against external plug-ins). We will then migrate this plug-in to use binary projects.

B1. Setting up the environment for binary self-hosting

B2. Importing binary projects

B3. Migrating XYZ Plug-in to binary projects

B4. Mixed-mode self-hosting

In this mode, we will import only the binary projects that are in the required subset of the entire external plug-in list. The rest of the plug-ins will be used as external.

B5. Migrating back to external plug-ins

It is possible to do a reverse migration at any time.

B6. Adaptive self-hosting and Plug-ins view

In the scenarios above, switching from external to binary projects was not automatic. Each time we changed the way required plug-ins were represented, the classpath didn't follow. We had to explicitly recompute it to make it in sync with the changed environment. PDE has an alternative way of representing required plug-ins using classpath containers. In this mechanism, all the required plug-in entries are replaced with one dynamic classpath container entry. This entry computes 'real' entries in real time - reacting to changes.

Scenario  C: Various tasks

C1. Converting Java projects into PDE projects

C2. Plug-in Search

C3. Plug-in Build and Export

C4. Dependency Extent and Unused Dependencies

Scenario D: Fragments

Prerequisite: In order to go through scenarios in this group, you need to finish scenario A2 and create com.example.xyz plug-in first.

D1. Fragment Project Creation

D2. Adding Fragment Extension

D3. Running the Fragment

Scenario E: Features

E1. Feature Project Creation

E2. Feature Manifest Editor

E3. Nested features

E4. Feature Preview

E5. Feature Build

Scenario F: Update Sites

This scenario shows how update sites can be built as workspace projects. A prerequisite is to have features created in scenario E.

F1. Creating a site project

F2. Working with the site manifest editor

<html>
<head>
<title>Sample Update Site Information</title>
</head>
<body>
<h1>Sample Update Site Information</h1>
<p>This file demonstrates how update sites can have
associated information pages.
</p>
</body>
</html>