| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html> |
| |
| <head> |
| <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 5.0"> |
| <meta name="ProgId" content="FrontPage.Editor.Document"> |
| <link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css"> |
| <title>PDE Tips and Tricks</title> |
| </head> |
| |
| <body> |
| |
| <h2>Tips and Tricks</h2> |
| |
| <p> </p> |
| <table border="1" cellpadding="10" cellspacing="0" width="600" style="border-collapse: collapse" bordercolor="#111111"> |
| <tr> |
| <td valign="top" align="right" 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="right" width="20%"><b>Exporting plug-ins, fragments |
| and features</b></td> |
| <td valign="top" align="left" width="80%">You no longer need to build |
| plug-ins, fragments, and features manually in your workspace and pollute |
| your workspace with build by-products. As of 2.1, using PDE's export |
| wizards, you can cleanly build and export plug-ins, fragments, and features |
| to a destination external to the workspace. You will be shielded from |
| the internal process of building, such as creating Ant scripts, running |
| targets, cleaning up, etc.</td> |
| </tr> |
| <tr> |
| <td valign="top" align="right" width="20%"><b>More robust build paths</b></td> |
| <td valign="top" align="left" width="80%">If you have found that sharing .classpath |
| files among team members is very difficult, as every developer has a |
| different workspace, then PDE's classpath container option is the answer. |
| Go to the <b>Plug-in Development->Java Build Path Control</b>, and check the |
| 'use classpath containers' option. You will need to update build paths |
| of your project in order to see the changes applied. Once you switch to |
| classpath containers, you can use either external plug-ins or import binary |
| plug-in projects, or a mix of both. Whatever you do, classpath container |
| will keep up with the changes and adapt.</td> |
| </tr> |
| <tr> |
| <td valign="top" align="right" width="20%"><b>Support for feature-based self-hosting</b></td> |
| <td valign="top" align="left" width="80%">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).</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.</td> |
| </tr> |
| <tr> |
| <td valign="top" align="right" width="20%"><b>Templates</b></td> |
| <td valign="top" align="left" width="80%">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="right"><b>Plug-in dependency extent</b></td> |
| <td width="80%" valign="top" align="left">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. 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>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.</td> |
| </tr> |
| <tr> |
| <td width="20%" valign="top" align="right"><b>Finding Unused Dependencies</b></td> |
| <td width="80%" valign="top" align="left">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="right"><b>Plug-in searches</b></td> |
| <td width="80%" valign="top" align="left">If you would like to find a |
| plug-in, fragment, extension, or extension point in your workspace or in an |
| external plug-in, you could use the new Plug-in Search tab on the Search |
| dialog.</td> |
| </tr> |
| <tr> |
| <td width="20%" valign="top" align="right"><b>Searching other plug-ins</b></td> |
| <td width="80%" valign="top" align="left">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> |
| <tr> |
| <td width="20%" valign="top" align="right"><b>Plug-in dependencies view</b></td> |
| <td width="80%" valign="top" align="left">If you would like to view all the |
| plug-ins required before your plug-in is activated, use the Plug-in |
| Dependencies view. This view can be opened by |
| selecting a plug-in manifest file (<code>plugin.xml</code>) and choosing <b>Open |
| Dependencies</b> from the context menu. It allows you to browse the |
| plug-ins it requires, the ones they require, and so on.</td> |
| </tr> |
| <tr> |
| <td width="20%" valign="top" align="right"><b>Log View</b></td> |
| <td width="80%" valign="top" align="left">You don't have to search for the |
| .log file on your file system anymore. The Log view is a more |
| convenient way to view the contents of the log.<p> |
| <img src="../guide/images/errorLog.gif" width=573 height=131 border="0" alt="Log View"></td> |
| </tr> |
| </table> |
| <p> <br> |
| <a href="../hglegal2003.htm"> |
| <img src = "../images/ngibmcpy2003.gif" alt="Copyright IBM Corporation and others 2000, 2003" border="0" width="324" height="14"></a> |
| </p> |
| </body> |
| |
| </html> |
