PDE Usage Scenarios

The following set of scenarios are designed to assist the Eclipse user community explore and test the Plug-in Development Environment (PDE).

Note that the different scenarios are independent of each other and can be executed in any sequence.

If you find a problem with a scenario step:

Open a Bugzilla defect against the PDE/UI component.
Include the build number (e.g. RC1, RC2 etc.).
Always prefix the Summary of the defect with the step number.

Setup

To be able to run the scenarios exactly as described below, you need Eclipse 3.0 RC1 (or later) installed.
Two steps that need to be done before executing any of the scenarios.
- Launch Eclipse on a new workspace.
- Dismiss the Welcome Page by clicking on the Go to Workbench icon.

Scenario A: Your first plug-in in less than 10 minutes

Objective: This is the out-of-the-box experience scenario. We will create a new plug-in, test it and deploy it in less than 10 minutes.

A0. Start the clock

A1. Creating a new plug-in project

A1.1 Bring up the New Project Creation wizard by selecting File > New > Project... from the top menu.
A1.2 Select Plug-in Project from the list, and click Next.
A1.3 Enter com.example.xyz as the name of the plug-in project, and click Next.
A1.4 Accept all defaults on the Project Structure page and click Next.
A1.5 Accept all defaults on the Plug-in Content page and click Next.
A1.6 On the Templates page, select the Create a plug-in using one of the templates checkbox. This will enable the list of templates below and disable the Finish button.
A1.7 Select the Hello World template from the list and click Finish. As its description indicates, this template will create a menu item and a toolbar item, which, when pressed, will pop up a dialog containing the phrase "Hello, world!".
A1.8 A dialog will come up asking you if you would like to switch to the Plug-in Development perspective. Answer Yes.
A1.9 A project will be created in your workspace, and the manifest editor, which is used to edit and manage all the plug-in's files, will open on the Overview page.

A2. Testing the Plug-in

A2.1 In the Testing section of the Overview page of the manifest editor, click on the Launch a runtime workbench link.
A2.2 The Eclipse splash screen will appear, and a second (runtime) workbench will appear within seconds.
A2.3 In the runtime workbench, dismiss the Welcome page. The Resource perspective will open.
A2.4 Verify that there is a new top-level menu Sample Menu in the menu bar and that it contains menu item Sample Action.
A2.5 Select the menu item, and verify that the Hello World dialog comes up. Dismiss the dialog.
A2.6 Verify that there is a toolbar button showing the blue Eclipse icon. Click it. The same Hello World dialog will come up. Dismiss the dialog.
A2.7 Close the runtime workbench.

A3. Deploying the Plug-in

A3.1 Select the com.example.xyz project in the Package Explorer view. From the context menu, select Export... The Export wizard will come up.
A3.2 From the list of wizards, select the Deployable Plug-ins and Fragments wizard, and click Next.
A3.3 Verify that the com.example.xyz plug-in is pre-selected in the wizard.
A3.4 In the Export Options section, choose to deploy as a directory structure.
A3.5 In the Destination section, browse for the installation directory of the Eclipse instance you are running, e.g. D:/Eclipse. Click Finish.
A3.6 When the export operation starts, verify that you see a progress dialog where you have the option to run the operation in the background if you choose to.
A3.7 Go to the Eclipse installation directory where you exported the plug-in and verify that:
- In the plugins subdirectory of the Eclipse installation, there is a new folder called com.example.xyz_1.0.0
- In the com.example.xyz_1.0.0 folder, there is a plugin.xml file, an xyz.jar JAR, and an icons folder.
- In the icons folder, there is a sample.gif file.
A3.8 Shut down Eclipse and restart.
A3.9 Verify that you see in your workbench the same Hello World menu and toolbar button that you saw in steps A2.4-2.6.
A3.10 Verify that the Hello World dialog comes up when you press the toolbar button or the Sample Action menu item.
A3.11 Delete the project from the workspace.
A3.12 Close the workbench.

A4. Stop the clock

Scenario B: Variations in Plug-in Project creation

B1. Creating a plug-in with a special encoding

B1.1 Change the default encoding of text files to UTF-16BE on the Window > Preferences...> Workbench > Editors preference page.
B1.2 Create a Hello World plug-in as described in section A1 above.
B1.3 Verify that: NO problem markers were generated in the Problems view. (Bug 56314)
B1.4 In the com.example.xyz package, open the XyzPlugin.java file and make sure its content is readable. (Bug 56314)
B1.5 Select the XyzPlugin.java file in the Package Explorer view and click Alt+Enter to bring up the Properties dialog. Select the Info property page and verify that the encoding of the file has been set to UTF-16BE.
B1.6 Repeat B1.5 for the plug-in's build.properties file and verify that the encoding of this file has been set to ISO-8859-1.
B1.7 Repeat B1.5 for the plug-in's plugin.xml file and verify that the encoding of this file has been set to UTF-8.
B1.8 Delete the project you created in B1.2
B1.9 Go back to the Windows > Preferences... > Workbench > Editors preference page and restore the default encoding of text files to Cp1252.

B2. Creating a plug-in with a MANIFEST.MF file

B2.1 Create a new plug-in project as described in section A1 above, with two differences:
- When you get to the Project Structure page (step A1.4), select the Create an OSGi bundle manifest for the plug-in checkbox.
- When you get to the Templates page (step A1.6), select the Plug-in with a View template. This template creates a sample view that will be added to the Resource perspective.
B2.2 Verify that the project created contains three files: META-INF/MANIFEST.MF, plugin.xml and build.properties, and that the Java code generated compiles without errors.
B2.3 Bring up the Launch Configuration Dialog by selecting Run > Run... from the top menu.
B2.4 In the list of configuration types, check if there are any configurations created of the type Run-time Workbench (i.e. if there is one left over from other scenarios). If so, reuse it and select the Clear workspace data before launching checkbox on the Arguments tab of the launch configuration. Otherwise create a new launch configuration and keep all defaults.
B2.5 Press Run to launch the runtime workbench, and answer Yes when/if asked to clear the workspace data.
B2.6 When the runtime workbench appears, dismiss the Welcome page. Verify that a Sample View appears at the bottom right corner of the Resource perspective.
B2.7 Close the runtime workbench.
B2.8 Delete the project from the workspace.

B3. Converting a Java project to a plug-in project

B3.1 Create a new Java project named com.example.java.
B3.2 File > New > Other.... Select the Convert Java to Plug-in Projects wizard under the Plug-in Development category. Click Next.
B3.3 The newly created project should be available as a choice. Select it and press Finish.
B3.4 Open the .project file of the project and verify that the project now has PDE nature and two PDE builders.
B3.5 Verify that a plugin.xml file with minimal content has been created for the project.

B4. Manifest files on demand

B4.1 Create a Hello World plug-in as described in section A1.
B4.2 Open its plugin.xml in the PDE manifest editor and go to the Runtime page.
B4.3 Verify that the Plug-in Activation section is disabled, as it is only available to plug-ins with a MANIFEST.MF file.
B4.4 Click on the link to create a manifest file.
B4.5 Verify that the line inviting you to create a manifest.mf file has vanished and the Plug-in Activation section is now enabled.
B4.6 Verify that the editor now contains a manifest.mf tab. Switch to it. Switch back to the Runtime page.
B4.7 Go to the newly created META-INF folder in your project and delete it.
B4.8 Verify that the Plug-in Activation section is now disabled again, the line asking you if you want to create a manifest.mf file is restored, and the manifest.mf tab is gone.

Scenario C: Plug-in Import and Export

C1. Importing a single plug-in

C1.1 On a fresh workspace, in the PDE perspective, open the plug-in import wizard via File > Import... > External Plug-ins and Fragments
C1.2 In the Import As section of the first page of the wizard, change the setting to Projects with source folders. Click Next.
C1.3 In the search text field, slowly enter org.eclipse.pde.ui and watch for the correctly matching plug-ins in the left viewer being selected as you type.
C1.4 Double-click on org.eclipse.pde.ui to move it to the right pane and press Finish.
C1.5 Verify that a project named org.eclipse.pde.ui is created in your workspace and that its source code is in a source folder called src-pdeui. No compiler errors.
C1.6 In the package explorer view, expand the Plug-in Dependencies container of the project and you should see that all the references made in the container are references to external JARs (i.e. they all have the JAR icon).
C1.7 Verify that source code has been successfully attached to all external JARs in the container. You can do so easily by looking at the JAR icon. If the source is attached, you will see an overlay at the bottom right of the JAR icon showing a document. Alternatively, you can expand any of the JARs, open an arbitrary class file and verify that you see source code.

C2. Importing plug-ins required by org.eclipse.pde.ui

C2.1 Select the org.eclipse.pde.ui project in your workspace, and open the plug-in import wizard again.
C2.2 Verify that the setting from C1.2 should have persisted. Change it to Binary projects.
C2.3 In the Plug-ins and Fragments to Import section, select the second option. Click Next.
C2.4 Verify that the org.eclipse.pde.ui plug-in is pre-selected in the left viewer and that the right viewer contains 55 plug-ins. Number might vary on non-Windows platforms. Press Finish.
C2.5 When the operation completes, expand the Plug-in Dependencies container for 5 randomly chosen plug-ins and ensure that none of the containers reference external JARs. They must all be referencing other projects. The exceptions, of course, are org.eclipse.osgi and org.eclipse.swt whose container must not reference anything, as they have no dependencies on any other plug-ins.

C3. Importing with links

C3.1 Open the plug-in import wizard, change the Import As setting to Binary projects with linked content, and select the first option in the Plug-ins and Fragments to Import section. Click Next.
C3.2 Click the Existing Unshared --> button. Verify that the label indicates that 56 plug-ins have been selected. (i.e. 55 from C2.4 + org.eclipse.pde.ui). Number might vary on non-Windows platforms. Click Finish and answer Yes to All when asked to overwrite existing plug-ins.
C3.3 Go to Window > Preferences > Workbench > Label decorations preference page, select the Binary Plug-in Projects decorator and click OK.
C3.4 Verify that all projects in your workspace acquire a 01 overlay on the top left quadrant of the project icon.
C3.5 Right-click the org.eclipse.debug.ui/dtui.jar and bring up its properties. Select the Info property page. Verify that the file type is listed as linked, and the path actually points to the location of the plug-in in your Eclipse install.
C3.6 Randomly open a class file from any of the plug-ins you imported and verify that source has been attached successfully.
C3.7 Delete all projects from your workspace.

C4. Exporting plug-ins en masse as a directory structure

C4.1 Using the plug-in import wizard, import the org.eclipse.team.* plug-ins (total of 6 plug-ins) as projects with source folders.
C4.2 Open the plug-in export wizard via File > Export... > Deployable Plug-ins and Fragments.
C4.3 Select all six plug-ins.
C4.4 In the Export Options section, select Deploy as a directory structure. Select Include source code.
C4.5 In the destination, enter a temp directory, e.g. D:\Temp. Click Finish.
C4.6 When the operation completes, verify that all six plug-ins are placed in a plugins subdirectory of the destination specified in C4.5.
C4.7 Verify that each plug-in has a JAR. Also verify that alongside each JAR is a zip file containing its source code.
C4.8 Delete said plugins directory.

C5. Exporting plug-ins in a zip via the wizard and via an Ant task

C5.1 Open the plug-in export wizard via File > Export... > Deployable Plug-ins and Fragments.
C5.2 Select all six plug-ins.
C5.3 In the Export Options section, select Deploy as a single deployable ZIP file.
C5.4 As a destination, enter the name of a zip file in a temp directory, e.g. D:\Temp\teamPlugins.zip.
C5.5 Select the Save this export operation as an Ant build script option.
C5.6 As a location for the ant script, enter the location of the org.eclipse.team.core plug-in in your workspace, and name the script exportPlugins.xml.
C5.7 When the operation completes, verify that the zip file has been created in the correct location.
C5.8 Open the zip file and verify that the path for all resources starts with plugins/.
C5.9 Verify that JARs for all six plug-ins are in the zip file.
C5.10 Rename the zip file to teamPluginsOld.zip.
C5.11 Right-click on the org.eclipse.team.core project in your workspace and select Refresh to bring in thee pluginExport.xml the wizard had created.
C5.12 Right-click on pluginExport.xml and from the context menu, select Run > Ant Build... Make sure you select the Ant Build menu item that has the ...
C5.13 In the Ant launch configuration dialog, go to the JRE tab. In the Runtime JRE section, select the Run in the same JRE as the workspace option. Press Run.
C5.14 The operation will run in the background. When it completes, make sure the end result is the same as in C5.7. The zip file created should be identical in size and content to teamPluginsOld.zip.
C5.15 Delete all zip files generated and all plug-in projects from your workspace.

Scenario D: Plugins View and Dynamic Classpaths

D1. Opening Files in the Plug-ins View

D1.1 On a fresh workspace, open the Plug-in Development perspective, and switch to the Plug-ins view.
D1.2 Verify that all plug-ins shown in the view have are expandable and their icon has the arrow overlay in the top-left quadrant, indicating that they are external plug-ins.
D1.3 Expand the org.eclipse.jdt.debug plug-in and double-click on its plugin.xml. Verify that the file will open in the PDE manifest editor.
D1.4 Verify that the file will be in read-only mode only. That is, the editor will not let you type anything in the source page, and all buttons and actions are disabled in the forms.
D1.5 Expand any of the fragments listed and double-click on its fragment.xml. Verify that the file will open in the PDE manifest editor.
D1.6 Verify that the file will be in read-only mode only. That is, the editor will not let you type anything in the source page, and all buttons and actions are disabled in the forms.
D1.7 Expand the org.eclipse.osgi plug-in and double-click on the META-INF/MANIFEST.MF file. Verify that the file will open in the PDE manifest editor. (Bug 64842)
D1.8 Verify that the file will be in read-only mode only. That is, the editor will not let you type anything in the source page, and all buttons and actions are disabled in the forms.

D2. Plug-ins View and Target Platform

D2.1 While the Plugins view is visible, open the Plug-in Development > Target Platform preference page. Deselect the org.apache.ant plug-in and click OK.
D2.2 Verify that the org.apache.ant plug-in now disappears from the view.
D2.3 From the drop down menu of the Plugins view, select Show disabled external plug-ins. Verify that the org.apache.ant plug-in will reappear in the view, but its icon will be hollow and its label will end with "-disabled".
D2.4 Go back to the Target Platform preference page, reselect org.apache.ant, and click OK. Verify that the plug-in's icon and label will go back to normal in the Plugins view.
D2.5 Create a Hello World plug-in named com.example.xyz as described in section A1.
D2.6 Switch to the Plugins View and verify that the new plug-in appears in the view. It would have a project icon and it is not expandable.
D2.7 Go back to the Package Explorer view and close the project. Switch to the Plugins view, the plug-in should have vanished from the list.
D2.8 Reopen the com.example.xyz project. Switch back to the Plugins view and verify that the plug-in is back again.
D2.9 Open the plugin.xml file of the com.example.xyz plug-in to the Overview page, and change its id to "com.example.abc". Save.
D2.10 Switch to the Plugins view and verify that the view has been correctly updated with the new plug-in ID.
D2.11 Open the plugin.xml file of the com.example.abc plug-in to the Overview page, and reset its id to "com.example.xyz". Save.
D2.12 Verify that the Plugins view has updated correctly.

D3. Dynamic Classpath

D3.1 In the Package Explorer view, expand the Plug-in Dependencies container of the com.example.xyz plug-in project, and verify that all its entries are references to JARs found in your target platform.
D3.2 Go the Plug-in Development > Target Platform preference page. Deselect all plug-ins. Click OK.
D3.3 Verify that the Plug-in Dependencies container of the com.example.xyz plug-in is now empty, and that you have 19 compiler errors in your Problems view.
D3.4 Go back to the Target Platform preference page. Select all plug-ins EXCEPT org.eclipse.core.runtime. Click OK.
D3.5 Verify that the Plug-in Dependencies container of the com.example.xyz shows references to 4 UI-related external JARs, and the number of compiler errors in the Problems view has now been reduced to 2.
D3.6 Using the plug-in import wizard, import org.eclipse.core.runtime as a project with source folders.
D3.7 Upon the completion of the import operation, verify that all compiler errors in com.example.xyz are gone.
D3.8 Verify that the Plug-in Dependencies container of com.example.xyz now shows a reference to the org.eclipse.core.runtime project.
D3.9 Close the org.eclipse.core.runtime project. Verify that compiler errors appear again in the com.example.xyz plug-in.
D3.10 Go the Target Platform preference page, select org.eclipse.core.runtime and click OK.
D3.11 Verify that the Plug-in Dependencies container of the com.example.xyz plug-in has now updated. It shows references to external JARs, and compiler errors are gone.
D3.12 Reopen the org.eclipse.core.runtime project. Verify that the com.example.xyz plug-in remains error-free and that its container now shows the org.eclipse.core.runtime project.
D3.13 Open the manifest editor of the org.eclipse.core.runtime plug-in. Go to the Overview page and append an S to its id. Save.
D3.14 Verify that the Plug-in Dependencies container of com.example.xyz no longer references the org.eclipse.core.runtime project.
D3.15 Also verify that com.example.xyz remains error-free.
D3.16 Revert the change made in D3.13 and save. Verify that the com.example.xyz remains error-free and its container once again references the org.eclipse.core.runtime project.
D3.17 Delete all projects from your workspace.

Scenario E: Debugging and Tracing

E1. Transparent Debugging

Objective: In this scenario, we will demonstrate how you can set breakpoints in source files, class files, linked libraries, external libraries that are part of the Java model, external libraries that are NOT part of the Java model, and how you will be able to debug, step in and out of any file transparently without you being aware where the file is coming from.

E1.1 On a fresh workspace, using the plug-in import wizard, import the org.eclipse.osgi plug-in WITH source.
E1.2 Import the org.eclipse.core.runtime plug-in as binary WITH links.
E1.3 Import the org.eclipse.ui plug-in as binary.
E1.4 Go to the Plugins view, right-click on the org.eclipse.pde.ui plug-in and select Add to Java Search. Verify that this will create a Java project in your workspace called External Plug-ins Libraries. When you expand it, you will see a classpath container called External Plug-ins. When you expand the container, you will find a reference to an external JAR in the org.eclipse.pde.ui plug-in.
E1.5 In the Package Explorer view, click on the Link With Editor toolbar button.
E1.6 From the top menu, Navigate > Open Type... Enter PluginImportWizard. Verify that it will open a class file found in the project created in E1.4. Set a breakpoint in the PluginImportWizard.addPages() method.
E1.7 Navigate > Open Type... Enter Plugin. This will open a class file in the linked library of the org.eclipse.core.runtime project. Set a breakpoint in Plugin.start(BundleContext) method.
E1.8 Navigate > Open Type... Enter BundleContextImpl. This will open a java file in one of the source folders of the org.eclipse.osgi project. Set a breakpoint in BundleContextImpl.getBundle() method.
E1.9 Navigate > Open Type... Enter AbstractUIPlugin. This will open a class file in the external library referenced by the org.eclipse.ui project. Set a breakpoint in AbstractUIPlugin.start(BundleContext) method.
E1.10 Start a runtime workbench in debug mode.
E1.11 The first breakpoint you will hit is the one in BundleContextImpl (i.e. in a source file). Verify that you can read the variables at that breakpoint. Disable the breakpoint so you won't hit it again and press Continue.
E1.12 The next breakpoint you hit will be the one in Plugin.start(BundleContext) - i.e. in a class from a linked library. Step over some of the statements. Verify that you can see the variables changing as you step over. Disable the breakpoint and press Continue.
E1.13 The next breakpoint you hit will be the one in AbstractUIPlugin.start(BundleContext) - i.e. a class in an external library that is part of the Java model. Step over the statements. Verify that your debugging experience is smooth. Disable the breakpoint and hit continue.
E1.14 When the runtime workbench comes up, dismiss the Welcome page. Bring up the Plug-in Import Wizard. You will hit the breakpoint in PluginImportWizard.addPages() - i.e. a breakpoint in a class coming from a library that is not part of the Java model. Step over a couple of statements and hit Continue.
E1.15 Dismiss the wizard. Close the runtime workbench.

E2. Tracing

E2.1 Open the launch configuration dialog. Create a new run-time workbench launch configuration or reuse an existing one.
E2.2 Go to the tracing tab. Select the Enable tracing for selected plug-ins option.
E2.3 Deselect all plug-ins and select the org.eclipse.osgi plug-in only.
E2.4 In the tracing options of the org.eclipse.osgi plug-in, turn the debug flag on. Press Run.
E2.5 In the console of the host workbench, you will see a lot of blue messages including ones indicating that plug-ins are being read, where they are read from, etc.
E2.6 Close the runtime workbench.

E3. Fine-grained control over the runtime classpath

E3.1 On a fresh workspace, create a Hello World plug-in named com.example.xyz, as described in section A1.
E3.2 Create a plug-in with a template view named com.example.view, as described in section A1.
E3.3 Launch a runtime workbench on a new workspace.
E3.4 Test the Hello World plug-in as in section A2. Verify that it works fine.
E3.5 Verify that the sample view appears in the bottom right corner of the Resource perspective.
E3.6 Close the runtime workbench.
E3.7 Right-click on the com.example.xyz plug-in and bring up its properties dialog.
E3.8 Select the Self-Hosting property page.
E3.9 Deselect the /com.example.xyz/bin folder. This will prevent the runtime classloader from not finding these classes at runtime. Click OK.
E3.10 Launch a runtime workbench.
E3.11 Verify that the sample view is OK.
E3.12 Verify that when you select the Sample Action menu item from the top Sample Menu, you will get a dialog saying "The chosen operation is not currently available".
E3.13 Open the log view of the runtime workbench via Window > Show View > Error Log. Verify that it contains log entries about classloading errors.
E3.14 Double-click on one of the log entries. This will bring up the Events Dialog. Use the Up and Down arrow to navigate from one entry to the next.
E3.15 Verify that the log entries that have a stack trace have a different icon (one with a document background) than log entries with no stack trace.
E3.16 Close the runtime workbench.

Scenario F: Search

F1. Expanding the Java search scope

F1.1 On a fresh workspace, open the Plug-in Development perspective and switch to the Plug-ins view.
F1.2 Select all the plug-ins. Right-click and select Add to Java Search from the context menu.
F1.3 Switch to the Resource perpective. Verify that an empty Java project named External Plug-in Libraries has been created and that it only contains three hidden files.
F1.4 Switch back to the PDE perspective and select Navigate > Open Type in Hierarchy from the top menu. Type Job. Click OK.
F1.5 Verify that the hierarchy for the type Job is successfully created. This actually shows you all the background jobs implemented in the SDK, and you did not have to import a single plug-in into your workspace.

F2. Plug-in Search

F2.1 Open the Plug-in search page via Search > Search... from the top menu.
F2.2 Search for all declarations of plug-ins whose name start with org.eclipse.team.*
F2.3 Verify that the search results in 6 hits.
F2.4 Verify that double-clicking on any of the hits will result in the manifest file of that plug-in to be opened in the manifest editor.
F2.5 Open the search page again, and search for all occurrences of extension point org.eclipse.core.runtime.applications.
F2.6 Verify that the search yields 12 hits. One for the extension point itself, and 11 extensions that plug into it.
F2.7 Double-click on any of the hits and verify that the manifest editor opens on the source page with the correct line highlighted.

F3. Dependency Analysis

F3.1 Using the plug-in import wizard, import the org.eclipse.pde.ui plug-in as binary and open its plugin.xml.
F3.2 Go the Dependencies tab. Select org.eclipse.search from the list and click on Compute Dependency Extent in the Dependency Analysis section. (Bug 64862)
F3.3 The search result should yield all the extension points and Java types declared in org.eclipse.search that are used by org.eclipse.pde.ui. The result should be 2 extension points, 6 interfaces and one class.
F3.4 Use the Add... button to add an extraneous dependency to the list (e.g. org.eclipse.compare). Save the file.
F3.5 Click on Find Unused Dependencies in the Dependency Analysis section, the search result will yield the plug-in you added in F3.4.

Scenario G: Features and Update Sites

G1. Feature Creation

G1.1 Using the plug-in import wizard, import org.eclipse.pde, org.eclipse.pde.build, org.eclipse.pde.core, org.eclipse.pde.junit.runtime, org.eclipse.pde.runtime, and org.eclipse.pde.ui as projects with source folders.
G1.2 Bring up the New Feature Creation wizard via File > New...> Feature Project.
G1.3 Enter org.eclipse.pde-feature as the project name. Click Next.
G1.4 Set the feature ID to org.eclipse.pde. Set the feature name to PDE Feature. Click Next.
G1.5 Leave all defaults on the Custom Install Handler page. Click Next.
G1.6 Select all six plug-ins from G1.1. Press Finish. Verify that the feature.xml for the feature project is open for editing.
G1.7 In the Feature URLs section, create a Discovery URL whose label is Main Eclipse Discovery Site and whose URL is http://update.eclipse.org/testUpdates.
G1.8 Create a new Update URL whose label is Main Eclipse Update Site and whose URL is http://update.eclipse.org/testUpdates
G1.9 Switch to the Information page and enter dummy content on all three tabs. Save the file.

G2. Update Site Creation

G2.1 Create a site project via File > New...> Project > Plug-in development > Update Site Project. Click Next.
G2.2 Enter site as the name of the project. Click Next.
G2.3 Select the option to generate a sample web page to preview the site. Press Finish. Verify that the site.xml file is open for editing.
G2.4 In the Features to Build section, add the org.eclipse.pde feature.
G2.5 In the Features to Publish section, create a new category whose label is Sample Category and whose name is sampleCategory.
G2.6 Drag and drop the org.eclipse.pde feature from the left viewer into the category created in the previous step. (bug 61834). Note: if drag and drop fails, right-click on the feature in the left viewer and select Publish from the context menu.
G2.7 Once the feature in under the category in the right viewer, double-click on it and set its label as PDE Feature in the properties dialog. Save the file.
G2.8 Right-click on the index.html file at the root of the site project and view the file in the system editor. Verify that the html page is well-formatted.
G2.9 In the Features to Build section, press the Build All button.
G2.10 When the build operation completes, verify that a feature Update JAR is created in the features folder of the site project, and 6 plug-in Update JARs have been created in the plugins folder.

Scenario H: Manifest Editors

Testing all the manifest editors that PDE provides (plugin, feature, fragment, site, and schema) exhaustively will quadruple the length of this testing document and consequently quadruple the amount of time it takes to complete the testing of PDE on each platform.

Therefore, I recommend to do adhoc testing on the editors (2-3 minutes on each), mainly to make sure that Eclipse Forms look good on all platforms.