view is a great UI concept for IDEs that enables developers to encapsulate a set of functionality. It is typically used in a “non-model” fashion, meaning the functionality is visible and active without interfering with your workflow. An example of a view is when an IDE’s workspace explorer gives you a “Tree View” of the files in your workspace or a “Console View,” which provides output for your IDE when building debug applications. These types of views are the same in both of the major open source Java IDEs: Eclipse and NetBeans.

In my last article, “Divided Loyalty: Create Plugins that Work in Eclipse and NetBeans,” I explained how to integrate large pieces of functionality into both Eclipse and NetBeans frameworks and how to integrate actions and menus into both IDEs. This laid the groundwork for understanding the differences in plugin description files and APIs. In this follow-up article, I’ll explain:

1. How to integrate a view into each platform.
2. The differences in plugin deployment structures and how to access resources, such as images and template files.

Integrate a View into Eclipse
There are two steps that need to be taken for Eclipse to correctly activate and display a view. The first step is to notify the framework that the plugin contains a view. This is achieved by adding an extension tag to the plugin.xml. The extension tag then notifies Eclipse that you are implementing a defined functionality that the IDE recognizes. The “point” attribute of the extension tag notifies Eclipse of the type of functionality you’re implementing?in this case I am adding a view designated by “org.eclipse.ui.views.” You will also need to provide the category that your view will be listed in. However, if you have already defined a category or wish to use a standard category this step isn’t necessary.

The second step is to define your view by providing the view tag with the display properties, the class to be instantiated, and the category the view is associated with.

Defining the View in plugin.xml
Now that Eclipse knows your plugin will contain a view when the end user activates it, the class provided as the “class” attribute of the view tag will be instantiated. In order for your view to work, you must implement the IViewPart interface. Eclipse provides a base implementation of the interface in the ViewPart class. As seen in the code below, my NexawebLayoutView class extends the ViewPart class and it has all the base functionality needed to implement a view.

Lastly, you will need to implement the createPartControl method, which is called during the creation of the view to give the class the opportunity to create the view’s UI.

public class NexawebLayoutView extends ViewPart     Tree     _tree = null;     public void createPartControl(Composite parent) {          _tree = new Tree(parent, SWT.NONE);          //This should initialize the display.          initializeTree();     } …}

Implementing the View Source Code
Now that I have implemented my view via the NexawebLayoutView and notified Eclipse that my plugin contains a view, Eclipse will display my view when the end user clicks the “Window -> Show View -> Other…” menu item. Eclipse also lists views in the “Window -> Show View” menu?if you want the view to be listed there you can create your own “perspective” and tell the perspective that you want the view displayed as a shortcut.

For the plugin shown below, I wanted to have the layout view be listed when the “Debug” perspective is active. Therefore in the plugin.xml, I added the extension tag with a point attribute of org.eclipse.ui.perspectiveExtensions. I also needed to notify Eclipse that I am extending the ID of the view for the shortcut I have created.

Integrate the View into NetBeans
In contrast to Eclipse, NetBeans doesn’t provide any framework in their module manifest file to help with views. The developer is responsible for creating the shortcut to the view and instantiating the view. In order to get your view to open correctly in NetBeans, you first need to create the action that will open your view. In the article, “Divided Loyalty Part I,” I described the process of creating an action for NetBeans, which you can now use as a template to integrate this action for launching the view.

In the class that implements the action, you need to create the view. To do this, use the window manager and find the “mode” (place to attach the view), then dock your newly created view into the mode. For my layout view, I wanted to dock it into the output mode?this area of the screen is along the bottom of a fresh NetBeans install. Now, I need to call the open method on my view to make the view visible.

public class PropertiesViewAction extends CallableSystemAction {           public void performAction() {               PropertiesView view = PropertiesView.getInstance();               //get window manager               WindowManager manager = WindowManager.getDefault();               Mode mode = manager.findMode("output");                mode.dockInto(view);               view.open();             }}

Instantiating the View Source Code
NetBeans provides a base class called ExplorerPanel that is needed to create a view. As shown below, I implement my layout view in the singleton pattern, which protects a class from being instantiated more than once (I only want one class to be created for the entire time the IDE is running). To create the singleton pattern for my class, I made my constructor “private” and provided access to the class through a public getInstance() method. Then, I synchronized the getInstance() method to protect it against different threads inadvertently creating more than one instance of my class. Now in my Constructor, I was required to initialize my views UI; this is where you add your code to create the UI for the view. The view will not be displayed until the open method is called.

public class LayoutView  extends ExplorerPanel {         /** Creates a new instance of LayoutView  */         private LayoutView() {               initialize();    }    public static synchronized PropertiesView getInstance() {      if (_instance == null) {         _instance = new PropertiesView();             }     return _instance;     }       //create the view's contents    private initialize() {               Panel panel = new Panel();               add(panel, BorderLayout.CENTER);    }    protected void updateTitle() {                setName("Nexaweb Layout View");         }}

Eclipse vs. NetBeans: Accessing Resources
In just about any plugin I can think of you will need to access resources such as images, templates, etc. Eclipse and NetBeans provide similar constructs to accessing resources, but please keep in mind that there are slight differences. In Eclipse, most of the display properties are supplied in the plugin.xml?this provides the Eclipse framework with the ability to display most of the UI without having to incur the overhead of loading up all the plugins. On the other hand, NetBeans takes into account that the class (that is providing the functionality) is responsible for returning the location of the resource. This means that NetBeans must load all the modules to properly display the UI.

Eclipse?Accessing a Resource
When you are required to provide the location of an image for an action in Eclipse, just add the icon attribute to the action tag. The value of the attribute is the location of the icon relative to the plugin directory. In the case of my action below, the value of the icon attribute is “icons/delete.gif”.

Eclipse often requires images that need to be entered programmatically?this can be accomplished by setting an image object into a method. For example, when trying to display an image for a TreeItem, you’ll need to call the TreeItem’s setImage method.

Image objects can be formed by creating an image descriptor using the ImageDescriptor’s createFromURL method and providing the location of the image to be loaded. From the ImageDescriptor object you get the ImageData, which is used to create the Image.

//create and return the new image descriptorImageDescriptor imageDescriptor = ImageDescriptor.createFromURL(url);ImageData imageData = imageDescriptor.getImageData(); Image     image = new Image(device, imageData, imageData.getTransparencyMask());

NetBeans?Accessing a Resource
In NetBeans, when providing a path to the image, simply provide the location of the image in standard directory format. For my OutlineViewAction’s iconResource method below, I return icons/outlineview.gif because it’s in the icons directory of my plugin’s jar file.

public class OutlineViewAction extends CallableSystemAction {     ...            protected String iconResource() {                  return "/icons/outlineview.gif";         }               ...}

Locations of resources can also be provided in the plugin’s manifest file. When providing a location to a resource via this mechanism, you’ll need to add the prefix nbresloc: to the location directory format to the resource. The locations of other resources are provided in a similar manner. In the code snippet below, I provide the location of an HTML file as well as the location of an image.

Eclipse vs. NetBeans?Plugin Deployment
Once your plugin is created, it’s time to make it ready for deployment so other developers will be able to leverage the functionality (keep in mind that the deployment structure of plugins in Eclipse and NetBeans are very different). I describe Eclipse’s plugin structure as “exploded” and NetBeans as an “archive” deployment (for those familiar with J2EE Web application deployment).

Deploying a Plugin in Eclipse
Eclipse offers two ways to deploy a plugin with the only difference being the location of the plugin directory:

Option 1
: Add your plugin directory directly into Eclipse’s plugin directory. This is an effective method if you have a simple plugin or you’re providing a zip file as the installation method for developers using your plugins.

Option 2
: Create a link file that provides the location of your plugin. This is an effective method if you are writing an installer to provide your plugin into a pre-existing Eclipse installation. This option is the best as it provides a way to have your own repository for the plugins you are providing. In the “links” directory under the Eclipse install, add a file foo.plugin.link. The content of the file is simply the location of the plugin repository.

path=C:/Program Files/Nexaweb/plugins

Deploying a Plugin in NetBeans
Deploying a plugin inside of NetBeans requires the plugin and resources to be packaged into a single jar file. The manifest file for the jar file contains information about the plugin. The most important piece of information provided is the location of the plugin’s OpenIDE-Module-Layer location?this is NetBeans’ version of plugin.xml. Once your module is packaged into a jar file correctly, place it in NetBeans’ “module” directory. When NetBeans starts, it will load up all the modules and integrate the functionality into its framework.

The sum of these two articles has provided you a foundation for creating quality plugins in both NetBeans and Eclipse. First, I focused on framework differences and how to integrate an “action” into both IDEs. This time around, I described the differences of the plugin structures and how to integrate a “view” into both IDEs. From this point moving forward, it is just a matter of coming up with the desired functionality and making it happen. There is a huge market quickly emerging around creating customized plugins and now that you have an understanding of the process involved, it’s time to start developing.