| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html> |
| |
| <head> |
| <meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2005. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > |
| <meta http-equiv="Content-Language" content="en-us"> |
| <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> |
| <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> |
| <meta name="ProgId" content="FrontPage.Editor.Document"> |
| <link rel="STYLESHEET" href="../book.css" type="text/css"> |
| <script language="JavaScript" src="PLUGINS_ROOT/org.eclipse.help/livehelp.js"></script> |
| <title>PDE Tips and Tricks</title> |
| </head> |
| |
| <body> |
| |
| <h2>Tips and Tricks</h2> |
| |
| <p> </p> |
| <table border="1" cellpadding="10" cellspacing="0" width="600"> |
| <tr> |
| <td valign="top" align="left" width="20%"> |
| <b>Creating a Rich Client Application</b> |
| </td> |
| <td valign="top" align="left" width="80%"> |
| The |
| <a class="command-link" href='javascript:executeCommand("org.eclipse.ui.cheatsheets.openCheatSheet(cheatSheetId=org.eclipse.pde.rcpapp)")'> |
| <img src="PLUGINS_ROOT/org.eclipse.help/command_link.png"><strong>Creating a Rich Client Application</strong></a> |
| cheat sheet will guide you through the individual steps to create a plug-in, |
| define a plug-in based product, customize a product, export a Rich Client Platform (RCP) |
| application and define a feature-based product using the Plug-in Development Environment (PDE). |
| </td> |
| </tr> |
| <tr> |
| <td valign="top" align="left" width="20%"> |
| <b>Creating an Eclipse Plug-in</b> |
| </td> |
| <td valign="top" align="left" width="80%"> |
| The |
| <a class="command-link" href='javascript:executeCommand("org.eclipse.ui.cheatsheets.openCheatSheet(cheatSheetId=org.eclipse.pde.helloworld)")'> |
| <img src="PLUGINS_ROOT/org.eclipse.help/command_link.png"><strong>Creating an Eclipse Plug-in</strong></a> |
| cheat sheet will guide you through the individual steps to create a plug-in, a plug-in extension, |
| a feature and an update site using the Plug-in Development Environment (PDE). |
| It will also demonstrate how to install and uninstall a feature using Install/Update. |
| </td> |
| </tr> |
| <tr> |
| <td valign="top" align="left" width="20%" height="345"><b>Feature-based |
| self-hosting</b></td> |
| <td valign="top" align="left" width="80%" height="345">The current method of self-hosting in Eclipse |
| is plug-in-based. PDE launches a second run-time workbench instance by |
| passing an array of plug-ins that it should load. A regular Eclipse |
| product is feature-based: during startup, it checks all the features that |
| should be active, computes plug-ins that belong to those features, and |
| passes the result for loading. |
| <p>This difference in behavior makes it complicated to self-host in |
| scenarios where a full startup that involves features is required. PDE now |
| supports this scenario if care is taken with the setup:</p> |
| <ol> |
| <li>The workspace needs to be <work-area>/plugins.</li> |
| <li>Features must be imported into the workspace using the new 'Feature |
| Import' wizard (they will be created in <work-area>/features).</li> |
| <li>All plug-ins must be in the workspace (either in source or imported |
| as binary projects WITHOUT linking).</li> |
| <li>When launching, Run-time Workbench launcher must be configured to |
| use features (in Plug-ins and Fragments tab).</li> |
| </ol> |
| <p>If all these conditions are met, the runtime Eclipse instance will be |
| launched in a way that is the closest possible approximation of a normal |
| Eclipse startup. This facilitates testing About dialogs and other aspects |
| that may depend on the set of installed features.</p></td> |
| </tr> |
| <tr> |
| <td valign="top" align="left" width="20%"><b>To clean or not to clean</b></td> |
| <td valign="top" align="left" width="80%">When you create a new runtime |
| workbench launch configuration, PDE presets the Program Arguments on the |
| launch configuration to include a -clean argument. |
| <p>This -clean argument clears all runtime-cached data in your runtime |
| workbench from one invocation to the next to ensure that all the changes |
| made in your host workbench, e.g. new Java packages were added to a plug-in |
| project, etc., are picked up when you launch a runtime workbench.</p> |
| <p>This clearing of the cache may hinder performance if your target platform |
| contains a large number of plug-ins. </p> |
| <p>Therefore, if you're in a situation where your target platform has a |
| large number of plug-ins and you're at a stage where you are not actively |
| adding/removing packages from your plug-in projects, you could remove the |
| -clean argument from the launch configuration to improve startup time.</p></td> |
| </tr> |
| <tr> |
| <td valign="top" align="left" width="20%"><b>Importing with linking</b></td> |
| <td valign="top" align="left" width="80%">Importing external plug-ins and |
| fragments can be time consuming and may result in large workspaces, |
| depending on the content of the plug-ins being imported. Therefore, |
| the 'Import External Plug-ins and Fragments' wizard gives you the option to |
| import with linking. This means that the import operation will not |
| copy the resources being imported into your workspace. It will simply |
| create links to the files being imported. You will be able to browse |
| these linked resources, as if they had been copied into your workspace. |
| However, they are physically not there on your file system, so you will not |
| be able to modify them. Beware of operations that depend on files |
| being physically in your workspace, as they will not work on linked |
| resources.</td> |
| </tr> |
| <tr> |
| <td valign="top" align="left" width="20%" height="112"><b>Templates</b></td> |
| <td valign="top" align="left" width="80%" height="112">For a quick start, PDE provides |
| several template plug-ins that will generate a plug-in with one or more |
| fully-working extensions. In addition, if at any point, you would like |
| to add a new extension from the template list (without having to generate a |
| plug-in), you could access these extension templates directly from the |
| manifest editor. From the 'Extensions' page of the editor, click |
| 'Add...'. In the wizard that comes up, select Extension Templates in |
| the left pane and choose the template of choice in the right pane.</td> |
| </tr> |
| <tr> |
| <td width="20%" valign="top" align="left" height="280"><b>Plug-in dependency extent</b></td> |
| <td width="80%" valign="top" align="left" height="280">If you have ever looked at the |
| list of plug-ins that your plug-in depends on and wondered why your plug-in |
| needs a particular plug-in X, now you can easily find out why. |
| <p>The <b>Compute Dependency Extent </b>operation |
| found on the context menu in several contexts (including manifest file |
| Dependencies page and Dependencies view) performs a combined Java and |
| plug-in search to find all Java types and extension points provided by |
| plug-in X which are referenced |
| by your plug-in. The results will be displayed in the Search view. When a type is selected in the Search results view, the <b>References |
| in <i>MyPlugIn</i></b> action in the context menu searches for the places |
| in the plug-in where the selected type is referenced. </p> |
| <p>If the |
| search returns 0 results, you should definitely remove plug-in X from your |
| list of dependencies, as it is not being used at all, and it would just slow |
| class loading.</p> |
| <p>The <b>Compute Dependency Extent</b> is also useful to check if you are |
| using internal (non-API) classes from plug-in X, which might not be |
| desirable.</p></td> |
| </tr> |
| <tr> |
| <td width="20%" valign="top" align="left" height="112"><b>Finding unused dependencies</b></td> |
| <td width="80%" valign="top" align="left" height="112">Minimizing a plug-in's number of |
| dependencies is certain to improve performance. As your plug-in |
| evolves, its list of dependencies might become stale, as it might be still |
| containing references to plug-ins that it no longer needs. A quick way |
| to check that all dependencies listed by your plug-in are actually used by |
| the plug-in is to run the 'Find Unused Dependencies' utility, which is |
| available through the context menu of the 'Dependencies' page of PDE's |
| manifest editor.</td> |
| </tr> |
| <tr> |
| <td width="20%" valign="top" align="left" height="80"><b>Extending the Java |
| search scope</b></td> |
| <td width="80%" valign="top" align="left" height="80">Java Search is limited to projects |
| in your workspace and external jars that these projects reference. If |
| you would like to add more libraries from external plug-ins into the search: |
| open the Plug-ins View, select a plug-in and choose <b>Add to Java Search</b> |
| from the context menu. This is handy for remaining |
| aware of other plug-ins that depend on ones you're working on.</td> |
| </tr> |
| </table> |
| |
| </body> |
| |
| </html> |
