e’ve come a long way from the days when the tools to which we most often turned to support us in developing applications were off-the-shelf commercial products. Today, thousands of developers have already adopted the open source frameworks Eclipse and NetBeans, and they haven’t looked back.

One of the advantages of using Eclipse or NetBeans, of course, is that these frameworks are open to being extended however you like. Not surprisingly, there is great interest and excitement around doing just that. Companies and individuals alike are learning how to take their own tools and create plugins to one or both of the popular IDEs. The advantages of doing so include not just better productivity for your own team of Eclipse/NetBeans users, but a large, potential new audience of users and customers for your tool itself.

For the last year, I have been developing plugins for both frameworks, discovering the differences between NetBeans and Eclipse, and designing a code base that can be reused as much as possible. I’ve learned that there is no magic API that will work in both IDEs. However, there is a way to structure your code to minimize the amount of “re-write” necessary to achieve success in both IDEs.

Where appropriate, I have leveraged code from an existing tool I developed that plugs into both IDEs. These IDE plugins provide a visual UI design tool for building rich Internet applications (RIAs) in a drag-and-drop fashion.

Analyze Your Tool’s Needs
A typical UI design tool will consist of one or more the following pieces of functionality that will need to be integrated into the IDE:

• Actions?Menu items and toolbar buttons that enable users to perform some kind of function.
• Wizards / Templates
• Preferences / Options
• Views
• Editors

Once you have decided what your tool needs to implement, you will need to architect your program to maximize code reuse. If you are integrating an existing tool into Eclipse and NetBeans, you will now have three applications to maintain. For this reason, it’s critical that you reuse as much code as possible.

Eclipse vs. NetBeans
Once you have decided on the functionality that your plugin will need, it’s time to integrate your tool into both IDEs, I’ll walk through the steps to develop the plugins. I will not cover the basic steps of creating your plugin projects here because both IDEs have a set of wizards to guide you through that process. Instead, I will focus on differences in the code needed to get a tool to work in both IDEs.

The first thing I want to do is integrate an action (menu item) into both environments. This is a good example case for doing other types of integrations because the code needed to integrate an action is similar to most other types of functionality.

Step 1?Define the action in the plugin’s manifest file. Both Eclipse and NetBeans have the concept of a manifest file that describes the integration points of the plugin. Eclipse’s manifest file is called plugin.xml. In NetBeans, you can specify the module’s manifest file in the Manifest.mf file of your module’s jar.

     Manifest-Version: 1.0     OpenIDE-Module-Specification-Version: 1.0     OpenIDE-Module-Layer: com/nexaweb/mf-layer.xml

Step 2?Implement the IDE’s action interface that will be called when the user clicks on the menu item or toolbar button. In order for the IDE to interact with your plugin’s functionality, you must implement an interface that the IDE knows about. This allows either NetBeans or Eclipse to invoke your object through reflection and then call method in classes. In the next section I show the interfaces you will need to implement to integrate an action into both IDEs.

Integrate the Action into Eclipse
First, I’ll show you how to integrate the action into Eclipse and how to notify Eclipse that your plugin contains an action. If you don’t notify Eclipse that your plugin contains an action the framework will not know where and how to display your action. In the plugin.xml file you need to add an extension tag and tell Eclipse that its extension is a popup menu. To do this, set the point attribute of the extension tag to org.eclipse.ui.popupMenus. Inside the extension tag, add an action tag. The action tag defines the display properties of the action and also the class to be called when the action is executed. The following is an example:

Now that Eclipse knows about the action, you need to implement the code to perform that action. IActionDelegate interface is a base interface that this action is required to implement in Eclipse. You will need to implement two methods: run and selectionChanged. The run method is called when the user performs the action. This is where you need to connect the plugin code to the underlying business logic.

public class PreviewAction implements IActionDelegate{    //Called to perform the action   public void run(IAction action) {      currentFile.preview();   }   //Called to notify the action that the selection has changed   public void selectionChanged(IAction action, ISelection selection){    }}

That completes the integration of your action into Eclipse. You defined your action in plugin.xml and then implemented the code to perform the action.

Integrate the Action in to NetBeans
To integrate the action into NetBeans, you first need to define your action in the module’s manifest file by adding a folder tag with a value of “Menu” for the name attribute. The “Menu” value notifies NetBeans that you are defining an action. Next, define the location of the action by using the folder tag with the name of the menu (to define the location of the menu in relation to other top-level menus use the attr tag). The value of the name attribute specifies that the menu is to be placed after the View menu.

Unlike Eclipse, specifying the display properties of your action is not done in the manifest file, but instead in a class that implements that action.

You implement the action by extending the CallableSystemAction class. In your action class you’ll need to implement the performAction method, which will be called when the user selects the menu item for this action. Now, implement the methods that supply NetBeans with the display properties for your action. To do this, implement the iconResource method and return the location of the image for the action, then the getName method that returns the display name for the action.

public class PreviewAction extends CallableSystemAction {    //Called to perform the action   public void performAction() {      currentFile.preview();  }   //Get the action's display icon   protected String iconResource() {      return "/icons/preview.gif";  }   //Get the action's display name   public String getName() {      return "Preview";   }}

Other pieces of functionality required by your tool such as views, options, wizards, and editors are executed in the same manner as the action.

User Interface Issues
One of the most important design decisions concerns which UI toolkit to use. Eclipse uses Standard Widget Toolkit (SWT) while NetBeans uses Swing/AWT. SWT is based on an operating system’s native UI toolkit and Swing, which is implemented in pure Java, does not use any native UI components. Fortunately, Eclipse provides a way to integrate Swing UIs into SWT frameworks. If you want to reuse your UI code, using Swing or some other pure Java UI toolkit is a good idea. (My company’s product, Nexaweb Designer, uses an alternative pure Java UI toolkit). Here’s how to add an AWT button to Eclipse:

//Create a new composite with the embedded style. Composite composite = new Composite(parent, SWT.EMBEDDED);//Create the AWT frameFrame frame = SWT_AWT.new_Frame(composite);//Create an AWT button on top of the frameButton button = new Button("This is an AWT button");//Add the button to the frameframe.add(button);

Integrating Swing/AWT into Eclipse does come with some caveats; currently only the Windows OS version supports this feature. However, in recent articles I have seen that more people have succeeded in getting it to work with GTK and Motif using an early-access JDK 1.5. If you’re in need of a solution that works on all platforms, then you may have to rewrite your UI code. Also when integrating Swing or AWT, the look and feel of the plugin will vary greatly from the overall IDE. The plugin developed for Eclipse, I limited the use of the AWT integration to the Visual Design Editor for Nexaweb’s rich Internet applications. This provided minimal impact to the workflow and feel of the application while maximizing the amount of code reuse.

The ability to develop a tool that will work in both Eclipse and NetBeans is a valuable luxury. I’ve explained the differences between the two frameworks and shown how to integrate the Swing UI into the eclipse SWT UI using code from Nexaweb’s Designer tool as an example. There is still much more to learn to successfully build a complete tool for both environments; both IDEs come with an vast set of APIs as well as the implementation details of developing other pieces of functionality. I hope this information will at least start you on a path for further exploration on the subject.