Plug-in development 101, Part 2: Introducing rich-client applications

Learn the basics about plug-in development and rich-client applications

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.

Share:

Chris Aniszczyk, Software Engineer, IBM, Software Group

Chris AniszczykChris 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.



01 April 2008

Also available in Russian Japanese

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
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)
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
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
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
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
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
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
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
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
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
Splash

Notice the new splash screen with a login and password.

Figure 12. Custom splash screen
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
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.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Open source on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Open source
ArticleID=297549
ArticleTitle=Plug-in development 101, Part 2: Introducing rich-client applications
publish-date=04012008