PDE/UI/TestPlan 3.4

Setup

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.

At the end of each scenario, it is recommended to delete all projects from your workspace so that one part does not interfere with the next.

End-to-End Scenarios

A Full Plug-in Development Cycle

• From the top level menu, select Help > Cheatsheets... > Plug-in Development > Creating an Eclipse Plug-in. Press OK.
• Go through this cheatsheet to explore all stages of the plug-in development cycle.

Creating an Rich Client Application

• From the top level menu, select Help > Cheatsheets... > Plug-in Development > Creating a Rich Client Application. Press OK.
• Go through this cheatsheet to create a standalone, fully-branded rich client application.

Search

Classic Plug-in Search

• From the top level menu, select Search > Search... to bring up the Search dialog.
• Click on the Plug-in Search tab. Enter *.debug.ui.* as a search string. Leave all defaults as-is. Press the Search button.
• Verify that the Search view opens and that it contains 31 hits.
• Double-click on the first hit to open the manifest editor of the org.eclipse.debug.ui plug-in.
• Verify that the editor opens to the plugin.xml source page and that the extension point ID is visible and correctly selected. Also verify that the arrow in the margin is on the correct line.
• Using the Down Arrow in the Search view toolbar, navigate to the next hit.
• Verify that the manifest editor for the org.eclipse.ant.ui plug-in opens with the extension hit visible and correctly selected.
• Press the Down Arrow again. Verify that the selection moves to another hit within the same editor. Verify that a new editor does NOT open.
• Close all manifest editors.

Plug-in Search in Mixed Namespaces

• Bring up the New Plug-in Project creation wizard via File > New > Project... > Plug-in Project. Press Next.
• Enter com.example.xyz as the project name. Press Next.
• Accept all defaults and press Finish. Answer Yes when prompted to switch to the Plug-in Development perspective.
• On the Extension Points page of the plug-in manifest editor, press Add...
• Enter org.eclipse.pde.core.parsers as the extension point ID. Enter Parsers as the extension point name.
• Uncheck the checkbox to edit the extension point schema. Press Finish.
• Verify that the extension point was created. Save the file and close the editor.
• Bring up the search dialog via Search > Search... from the top level menu.
• On the Plug-in Search tab, enter org.eclipse.pde.core.* as the search string. In the Limit To group, select Declarations. Press the Search button.
• Verify that the search view opens with 5 matches.
• Double-click on the org.eclipse.pde.core.parsers search hit. Verify that it correctly locates the extension point on the plugin.xml source page of the com.example.xyz plug-in.
• Double-click on the org.eclipse.pde.source search hit. Verify that the extension point declaration is correctly located on the plugin.xml source page of the org.eclipse.pde.core plug-in.

PDE as a Java Search Participant

• Check out the org.eclipse.pde.core plug-in project from HEAD.
• Right-click on the org.eclipse.pde.core.plugin package and select References > Workspace from the context menu..
• Verify that you get a search hit in the MANIFEST.MF file of the plug-in.
• Double-click on the search hit. Verify that the manifest editor opens on the MANIFEST.MF source page with the org.eclipse.pde.core.plugin package highlighted in the Export-Package header.
• Close the editor.
• In the Package Explorer view, select References > Workspace from the context menu of the org.eclipse.pde.internal.core.variables.TargetHomeDynamicVariableResolver.
• Verify that you get a search hit in the plugin.xml file of the plug-in.
• Double-click on the search hit. Verify that TargetHomeDynamicVariableResolver is highlighted in the resolver attribute of the org.eclipse.core.variables.dynamicVariables extension.

PDE as a Refactoring Participant

Renaming Types

• Bring up the New Plug-in Project creation wizard via File > New > Project... > Plug-in Project. Press Next.
• Enter com.example.abc as the project name. Press Next.
• Accept all defaults. Press Next.
• Choose the Hello World template. Press Finish.
• In the Package Explorer view, select Refactor > Rename... from the context menu of the com.example.abc.Activator type.
• Enter BundleActivator as the new name and press Finish.
• Turn to the MANIFEST.MF source tab of the plug-in editor and verify that there is no warning next to the Bundle-Activator header and that its value has been updated to reflect the new type name.
• In the Package Explorer view, select Refactor > Rename... from the context menu of the com.example.abc.actions.SampleAction type.
• Enter NewAction as the new name and press Finish.
• Turn to the plugin.xml source tab of the plug-in editor and verify that there is no warnings in the margin and that the class attribute on line 21 references the new type name.

Renaming Packages and Subpackages

• Turn to the Runtime page of the manifest editor of the com.example.abc plug-in.
• In the Exported Packages section, press Add...
• Verify that the selection dialog shows two packages. Select them both and save the file.
• In the Package Explorer view, select the com.example.abc package and select Refactor > Rename... from the context menu.
• In the Rename dialog, check the Rename subpackages checkbox.
• Enter com.example.abc.def as the new package name. Press Finish.
• Verify that NO warnings appear on the MANIFEST.MF or the plugin.xml files.
• Turn to the MANIFEST.MF source tab of the plug-in editor and verify that the Bundle-Activator and Export-Package headers are now referencing the new package name.
• Turn to the plugin.xml source tab of the plug-in editor and verify that the class attribute on line 21 references the new package name.

Cool Wizards

Externalize Manifests Wizard

• Create a Hello World plug-in by repeating steps C1.1 - C1.4
• Select the com.example.abc plug-in project and select Properties from its context menu.
• On the Plug-in Development > Plug-in Manifest Compiler preference page, choose the Use project settings option.
• Raise the severity level for Usage of non-exteranlized strings from IGNORE to ERROR. Press OK.
• Answer Yes when prompted to rebuild the project.
• Verify that the MANIFEST.MF file now has 2 errors and the plugin.xml has 4 errors.
• Right-click on the com.example.abc project and select PDE Tools > Externalize Strings... from the context menu.
• Verify that the Bundle-Name and Bundle-Vendor headers in the MANIFEST.MF file are flagged as non-extenalized.
• Verify that there are four attributes in the plugin.xml that are flagged as non-externalized.
• Accept all defaults and press Finish.
• Verify that all errors have gone away.
• Verify that a plugin.properties file was created at the root of the project containing six key-value pairs.
• Verify that attributes/headers flagged in steps 8 and 9 now have keys that start with %

Organize Manifests Wizard

• Check out the org.eclipse.pde.ui plug-in project from HEAD.
• Open the manifest editor for the org.eclipse.pde.ui plug-in and go to the Runtime tab.
• In the Exported Packages section, remove the org.eclipse.pde.ui.launcher and org.eclipse.pde.internal.ui.wizards.xhtml from the list.
• Switch to the plugin.xml tab. On line 17, remove the $nl/ prefix from the value for the icon attribute. Save the file.
• Bring up the Organize Manifests wizard via PDE Tools > Organize Manifests... from the context menu of the org.eclipse.pde.ui plug-in project.
• Keep all default options. In the Internationalization section, check the first option. Press Finish.
• This should undo the damage done in steps 3 and 4.
• Select Compare With > Latest from HEAD from the context menu of the org.eclipse.pde.ui plug-in project.
• Verify that there are no differences.