Creating a Rich Client Application
|
The
Creating a Rich Client Application
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).
|
Creating an Eclipse Plug-in
|
The
Creating an Eclipse Plug-in
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.
|
Feature-based
self-hosting
|
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.
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:
- The workspace needs to be <work-area>/plugins.
- Features must be imported into the workspace using the new 'Feature
Import' wizard (they will be created in <work-area>/features).
- All plug-ins must be in the workspace (either in source or imported
as binary projects WITHOUT linking).
- When launching, Run-time Workbench launcher must be configured to
use features (in Plug-ins and Fragments tab).
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.
|
To clean or not to clean
|
When you create a new runtime
workbench launch configuration, PDE presets the Program Arguments on the
launch configuration to include a -clean argument.
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.
This clearing of the cache may hinder performance if your target platform
contains a large number of plug-ins.
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.
|
Importing with linking
|
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. |
Templates
|
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. |
Plug-in dependency extent
|
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 Compute Dependency Extent 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 References
in MyPlugIn
action in the context menu searches for the places
in the plug-in where the selected type is referenced.
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.
The Compute Dependency Extent is also useful to check if you are
using internal (non-API) classes from plug-in X, which might not be
desirable.
|
Finding unused dependencies
|
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. |
Extending the Java
search scope
|
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 Add to Java Search
from the context menu. This is handy for remaining
aware of other plug-ins that depend on ones you're working on. |