Browse DevX
Sign up for e-mail newsletters from DevX


Divided Loyalty, Part 2: Creating Views and Deploying Plugins in Eclipse and NetBeans : Page 3

Views are an important aspect of any IDE but Eclipse and NetBeans users can write their own custom views and deploy them using each product's unique plugin architecture. Find out how to integrate a single view into either Eclipse, NetBeans, or both.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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

<action id="com.nexaweb.designer.delete" label="Delete" icon="/icons/delete.gif" disabledIcon="/icons/disabled_delete.gif" tooltip="Delete the selected item"/>

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 descriptor ImageDescriptor 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.

<file name="Empty UI File" url="nbresloc:/templates/empty.xml"> <attr boolvalue="true" name="template"/> <attr name="SystemFileSystem.icon" urlvalue="nbresloc:/icons/newXulToolbar.gif"/> <attr name="templateWizardURL" urlvalue="nbresloc:templates/help/empty.html"/> <attr name="SystemFileSystem.localizingBundle" stringvalue="com.nexaweb.Bundle"/> </file>

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.

Robert Buffone is a principal software architect responsible for platforms and tools at Nexaweb Technologies, Inc. Before Nexaweb, Buffone was with Trakus, a technology company for tracking sports in real-time. He has deep experience and knowledge about Windows technologies as well as Java, and is a leading expert in user interface design and application development.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date