Plug-in development 101, Part 2: Introducing Rich-Client Applications

DZone 's Guide to

Plug-in development 101, Part 2: Introducing Rich-Client Applications

· Java Zone ·
Free Resource

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.

[img_assist|nid=2738|title=Figure 1. Plug-in development workflow|desc=|link=none|align=undefined|width=500|height=290]


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.

[img_assist|nid=2827|title=Figure 2. Build configuration (build.properties)|desc=|link=none|align=undefined|width=572|height=468]

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.


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.

[img_assist|nid=2828|title=Figure 3. Export plug-in wizard|desc=|link=none|align=undefined|width=438|height=531]

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.

[img_assist|nid=2829|title=Figure 4. Plug-in on disk |desc=|link=none|align=undefined|width=572|height=105]

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.

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

[img_assist|nid=2830|title=Figure 5. Rich-client application template|desc=|link=none|align=undefined|width=487|height=396]

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.

[img_assist|nid=2831|title=Figure 6. New product configuration wizard|desc=|link=none|align=undefined|width=500|height=476]


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.

[img_assist|nid=2832|title=Figure 7. Overview|desc=|link=none|align=undefined|width=553|height=655]

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

[img_assist|nid=2833|title=Figure 8. Launching applications|desc=|link=none|align=undefined|width=533|height=327]


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.

[img_assist|nid=2834|title=Figure 9. Configuration|desc=|link=none|align=undefined|width=551|height=655]


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.

[img_assist|nid=2835|title=Figure 10. Launching|desc=|link=none|align=undefined|width=558|height=653]


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

[img_assist|nid=2836|title=Figure 11. Splash|desc=|link=none|align=undefined|width=572|height=627]

Notice the new splash screen with a login and password.

[img_assist|nid=2837|title=Figure 12. Custom splash screen|desc=|link=none|align=undefined|width=455|height=295]


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.

[img_assist|nid=2838|title=Figure 13. Branding|desc=|link=none|align=undefined|width=572|height=653]



Get products and technologies


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}