Developing Eclipse Plugins
To start the actual plugin development, you need to start with an Eclipse installation. For this example, we downloaded the latest Eclipse version at the time of this writing, v3.0.2, from the Eclipse site. As we use the CDT plugin for C and C++ development extensively in our own organization, we then downloaded the CDT v2.1 Project. It can be accessed under the Eclipse Tools Project from the projects link on the main Eclipse page. You can download both of these as .zip files, which extract into a /eclipse directory. Therefore, make sure you install the Eclipse zip file prior to the CDT zip file. In our case, we were building on Red Hat Linux 9.0 using the GTK- version of both the Eclipse framework and the CDT plugin, but the Motif versions work equally as well. We then brought up Eclipse with ./eclipse and selected the Plugin Development Environment (PDE) perspective from Window→Open Perspective.
Many texts on Eclipse plugin development walk users through the Hello World type of project. It is this author's belief that although that might be a good start for novice programmers, it is absolutely the worst way for experienced software developers to begin using Eclipse. It takes too long, and worst of all, much of the work has to be redone once you need to create a real plugin. Instead, we usually recommend creating as nearly complete a plugin project as possible, using as many pre-existing templates as the environment allows. Doing so gives you a considerable amount of functionality immediately. You then can develop your own customizations of the existing functionality without worrying about being properly attached or hooked to the normal plugin-type environment.
In the PDE, the Plugin Wizard allows a developer to create a sample plugin project quickly and easily, simply by selecting File→New→Plug-in Project. When prompted for a name of the plugin, we use a common syntax used by other commercial vendors. That is, we name the plugin with the text com.companyName.productName or in this example, com.mcc.dataView, as shown in Figure 1.
It is easy enough to remove functionality from the plugin project once we get started on some actual customizations, so we select Next for two screens until we reach the Templates screen. We then select Create a plugin using one of the template's boxes and choose to use the Custom Plugin Wizard. You then select Next to see the templates to be created.
You could remove specific functionality at this point, but for this exercise, we retain all functionality and simply keep selecting Next until we reach the Main View Settings window. In this window, we rename the Sample View as Data View, as shown in Figure 2. Once you have modified this window appropriately, you can select Finish or cycle through the last of the customization sections, which is View Features. You can move forward and back during this process, so take your time. No changes are made to the environment until the Finish button is selected.
If you mess it up the first time, as this author did, don't hesitate to delete the entire project including the directory contents and start again until you get it right. Once the plugin has been created to your exact template specifications, you are ready to execute the plugin for the first time. For this we use the run-time workbench.
One of the most attractive features of the Eclipse framework is its own ability to develop, test, debug and execute plugins in the run-time workbench. Few development environments provide exactly this kind of functionality in such an easy-to-use and intuitive fashion. This removes many of the time-wasting impediments to developers stuck in the long compile-build-debug cycle typical of other development environments.
To execute the DataView plugin, simply select Run→Run As→6 Run-time workbench from the PDE perspective. The Eclipse PDE spawns a completely separate user workspace, called the run-time workspace, and executes the DataView plugin. On the first execution of the plugin, you need to select the Window→Show View→Other top-level menu pull-down, and choose the DataView listed under the specific Views heading that you selected during plugin creation.
In future executions, the run-time workbench functions much as the regular workspace functions and retains the appropriate View layout between multiple launches. This greatly simplifies testing, as re-testing is only a matter of running the run-time workbench again.
One of the few drawbacks to the run-time workbench model is its rough doubling of host RAM usage due to executing the equivalent of two Eclipse sessions on a single machine. In systems with limited RAM, such as laptop environments, this can be a bit slow and frustrating. As JVMs improve, though, this problem does get better.
Experiment with the sample plugin menus and pull-downs to get a feel for what functionality you have created. Even though we don't discuss Editor customizations in this article, you also might want to experiment with creating a simple Eclipse project and then creating a new file with a .mpe extension. Doing so allows you to get familiar with the concept of multipage editors similar to the one used for displaying the plugin.xml file now listed under your new plugin project.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- Users, Permissions and Multitenant Sites
- New Products
- Flexible Access Control with Squid Proxy
- High-Availability Storage with HA-LVM
- Security in Three Ds: Detect, Decide and Deny
- Tighten Up SSH
- Non-Linux FOSS: MenuMeters
- Nmap—Not Just for Evil!
- diff -u: What's New in Kernel Development
- DevOps: Everything You Need to Know