 | Level: Intermediate Chris Aniszczyk (zx@us.ibm.com), Software Engineer, IBM
01 Apr 2008 Plug-in development in Eclipse is somewhat of an art form. If you're new to the
concept of plug-ins, especially in the context of OSGi and Eclipse, it can be a burden
learning the myriad tools Eclipse has to help you write plug-ins. This
article will help you learn some basic plug-in development skills, with some best
practices sprinkled in for good measure.
This "Plug-in
development 101" series of articles is all about developing plug-ins. But
before we get started, we need to ensure that we have a proper environment in which to
develop plug-ins. The first step is to download an Eclipse distribution that has the
Plug-in Development Environment (PDE) in it from Eclipse.org. I recommend downloading
the latest version of Eclipse Classic. In this series, we will use a milestone
release of Eclipse V3.4 (M5). Once this done, you're ready to go. (See Resources to learn where to find Eclipse and additional
background information if you are new to Eclipse.)
To make it easier to understand plug-in development, this article follows a workflow
detailed in Figure 1. In Part
1, we discuss the first five steps of the workflow. Here,
we cover the last two steps and focus on introducing rich-client applications.
Figure 1. Plug-in development workflow
Building
Configuring build content is an important step on our plug-in development adventure. In
Eclipse, all plug-in development build-related configuration goes into the
build.properties file.
Figure 2. Build configuration (build.properties)
|
Automated builds?
Setting up an automated build for a plug-ins is outside the scope of this article, but
since it's such a frequent question, here's some background. The most common way to set up
automated builds is with the PDE Build component in the Eclipse SDK. The downside
to PDE Build is its complication, which beginners find daunting. A quick way to see how
to set up an automated build is reviewing the plug-ins and tools at the Pluginbuilder
Web site (see Resources). |
|
Sample build-configuration content centers around the MANIFEST.MF, plugin.xml, and icon
files. It may also include plugin.properties for internationalization support or
artifacts like license files. It's important to notice the distinction of what is
included in a binary build vs. a source build. Typically, when you export
a plug-in from Eclipse, it's just a binary plug-in export that can be used by your
friends in their Eclipse installations. A Source Build should include the source from
the plug-in you're working on. You can elect to do a source build during a typical
export operation.
Exporting
The final step in a typical plug-in developer's workflow involves exporting the
plug-in you've created. Eclipse's PDE makes this an
easy process using a specialized export wizard. To access this wizard (see Figure 3),
simply click File > Export and select Deployable Plug-ins and Fragments
under the Plug-in Development category.
Figure 3. Export plug-in wizard
The first option to select within this wizard is what plug-ins we're interested in
exporting. In this case, we just want our simple HelloWorld plug-in. The next step is
to select a destination for our plug-in. We can opt to put the plug-in inside a ZIP
file or within a directory. The other options within this wizard include abilities to
do plug-in signing and bundling source with your plug-in. For now, ignore these and
simply click Finish on the wizard to export your plug-in (see Figure 4).
Note that the Overview page in the plug-in manifest editor provides an easy hyperlink to launch the wizard.
Figure 4. Plug-in on disk
That's it! That's all it takes to get a plug-in from an Eclipse workspace to a
consumable form on a hard disk. Once in this form, plug-ins can be distributed easily to
colleagues and friends. This ends our focus on plug-in development workflow, but now
that we know the basics, we can start looking at what it takes to create a rich-client application within Eclipse.
|
Rich Client Platform
Rich-client applications are enabled in Eclipse using the Rich Client Platform (RCP).
Traditionally, the Eclipse platform is designed to serve as an open tools platform.
However, it is architected so its components could be used to build just about any client
application. The minimal set of plug-ins needed to build a rich-client application is
collectively known as the Rich Client Platform. See Resources to
learn more. |
|
Products
To create a rich-client application within Eclipse, we need to work with a concept
called product configurations. Product configurations are what PDE provides as a
way for plug-in developers to build rich-client applications. To understand product
configurations, we need to have a sample rich-client application to work with. We'll
create one by taking advantage of the PDE template mechanism we went over in Part 1. Create a plug-in project named rcp and make sure to indicate that its a rich-client application,
then select the RCP Application with a view template (see Figure 5).
Figure 5. Rich-client application template
The next step is to create a product configuration file to help assemble the
rich-client application we previously created. To create a new product configuration,
right-click on the plug-in project and select New > Product Configuration to
launch the new product configuration wizard (see Figure 6). Accept all the
defaults, use rcp.product for the name of your product
configuration file and click Finish to launch the product configuration editor.
The next sections will go over the various pages of the product configuration editor.
Figure 6. New product configuration wizard
Overview
Similar to the plug-in manifest editor, the first page presented within the product
configuration editor is the Overview tab (see Figure 7). It
gives a quick synopsis of the product configuration, convenient links to test and
export products, and the ability to select whether the product is based on plug-ins or
features. To quickly test applications, select the Launch an Eclipse application
link within the Testing section and see what the rich-client application looks like.
Figure 7. Overview
That's all there is to the Overview tab within the product configuration editor. If
you're interested in the basic operations you can do on product configurations, head
back to Overview.
It is also possible to launch your application from here. For example, click the
Launch an Eclipse application and you should see your application pop up (see Figure 8).
Figure 8. Launching applications
Configuration
The Configuration tab contains the basic building blocks needed to run your product.
This includes information such as the artifacts needed to run your product. The first
section, Plug-ins and Fragments, simply lists the plug-ins and fragments
needed to run your product. As a helpful tip, there will be times when you're working
on your product and dependencies will be introduced. When this happens, it's always
keen to select the Add Required Plug-ins to calculate if anything needs to be
added to your product configuration.
The next section, Configuration File, represents
an OSGi-specific artifact called the config.ini file. About 99.9 percent of the time,
you want to leave this setting alone and have Eclipse generate the file. All this file
contains really is what you have specified in the previous plug-ins and fragments
section, but in a special format Eclipse can understand when launching.
Figure 9. Configuration
Launching
The Launching tab contains all the information that deals with launching your
Eclipse-based product. The Java Runtime Environment section allows you the
convenience of bundling platform-specific JREs. The Program Launcher section
allows you to customize the executable that launches the product. For example, it's
common that developers want something other than eclipse.exe for the name of
their launcher executables. On top of naming the launcher executable, you can also
brand it using platform-specific icons. The Launching Arguments section allows
you to specify platform-specific launch parameters for your product. This may be useful
if you want any special behavior on an operating system, such as Mac OS X.
Figure 10. Launching
Splash
The Splash tab allows you to optionally configure a splash screen for your product
(see Figure 11). For example, when you launch Eclipse, you get a simple splash screen
that says Eclipse and shows loading plug-in progress. By default, your example RCP
application came with a simple bitmap-based splash screen. However, to demonstrate the
interesting things you can do with your splash screen, we'll take advantage of the
login splash screen template (in the Customization section). Once you select the log-in
template, save your product configuration and launch your application.
Figure 11. Splash
Notice the new splash screen with a login and password.
Figure 12. Custom splash screen
Branding
The Branding tab (see Figure 13) allows you to do three things: customize window
images, create a custom about dialog, and create an optional welcome page. Window images
are simply the images associated with your application shell windows. For example, when
you launch Eclipse, the title bar has a little 16x16 Eclipse icon. These are the types
of icons you can customize. Most software applications have some form of an about dialog
to list things like licenses, authorship, and version information. The product
configuration editor lets you reuse the existing Eclipse about dialog, but customize it
with your own images and information.
The welcome page is something you can create to
aid your users in learning your application. For example, to see the default Eclipse
Welcome page, simply select the Help > Welcome menu item. If you desire
something similar for your application, you can start the process in the Welcome
Page section of the Branding tab. Since creating a welcome page is outside the scope
of this article, to learn more, please consult Resources to
discover more information about Eclipse user-assistance technologies.
Figure 13. Branding
Conclusion
On the whole, this "Plug-in
development 101" series' mission was to give an introduction to the basics of
plug-in development with some best practices sprinkled in. We accomplished that in Part 1 by
creating a sample plug-in and going through a typical plug-in development workflow. In
Part 2, we finished going through our plug-in development workflow and created a
rich-client application. Once the workflow is mastered, it becomes much easier to
develop plug-ins and Eclipse RCP-based applications.
Now, go forth and use your newly found knowledge to create plug-ins and Eclipse-based
applications.
Resources Learn
Get products and technologies
Discuss
-
The Eclipse Platform newsgroups should be your first stop to discuss questions regarding Eclipse. (Selecting this will launch your default Usenet news reader application and open eclipse.platform.)
-
The Eclipse newsgroups has many resources for people interested in using and extending Eclipse.
-
Participate in developerWorks blogs and get involved in the developerWorks community.
About the author | 
| | Chris Aniszczyk is an Eclipse committer at IBM Lotus who works on OSGi-related development. His primary focus these days is improving Eclipse's Plug-in Development Environment (PDE) and spreading the Eclipse love inside of IBM's Lotus organization. He is an open source enthusiast at heart, specializing in open source evangelism. He evangelizes about Eclipse in his blog, and he's honored to represent the Eclipse committers on the Eclipse Foundation's board of directors. He's always available to discuss open source and Eclipse over a frosty beverage. |
Rate this page
| |
