Compartir en:

eclipse-fb

When it comes to Eclipse Plugin development, the information you can find on the web is disorganized and somewhat foggy, so you’ll probably spend half of your time reading forums and blogs to solve different problems. Instead of presenting an advanced tutorial, I would like to share a compendium of useful links and tips that I found useful.


Set up your environment Supposing you already have a version of Eclipse, check to see whether you have Plugin Development Tools installed:

  • Go and check your Eclipse Project Update Site (you can do this from Help->Install New Software… and choose http://download.eclipse.org/eclipse/updates/x.x – where x.x is which Eclipse version you have. Mine is 4.3 BTW)
  • There you should have all of the components under Eclipse Plugin Development Tools installed, and you should also install Eclipse RCP Plug-in Developer Resources under Eclipse RCP Target Components.

If you don’t have Eclipse installed yet, just download the Eclipse Standard edition which contains all the necessary tools. When that’s done, you can try to build a sample plugin. Eclipse provides some samples for you to try, or you can watch a good tutorial here. Learn a bunch of new terms One of the things that can help a lot is actually understanding some of the new terms you’ll run into when developing a plugin.

  • Plugins: A plug-in is used to group your code into a modular, extendable and sharable unit. Plugins are basic units of any Eclipse-based product or any Eclipse extension;
  • Features: A feature is used to package a group of plug-ins together into a single installable and updatable unit. Features may contain many plugins or even other features;
  • Extension Points: When a plug-in wants to allow other plug-ins to extend or customize portions of its functionality, it will declare an extension point;
  • Extensions: Plugins that want to connect to an extension point must implement that contract in their extension. This allows plug-ins built by different individuals or companies to interact seamlessly, even without their knowing much about one another;
  • Workbench: The Eclipse workbench is a virtual UI component that  provides the framework for the application and is responsible for displaying all other UI components;
  • Windows: Eclipse applications usually have more windows. Typically they will have one, but you are not limited, for example if you have multiple monitor applications;
  • Parts: These are the basic unit of Eclipse workbench, and there are two types: editors and views.

There are a lot more new terms you’ll learn along the way. For further reference, check out these sites:


Listening to your environment While building your plugin, you may need to be notified of several things happening around you and subsequently react to them. Eclipse can notify you of lots of events. I thought it might be a good idea to make a list with some of the main ones with information on how to handle them. Resource changes Any file, directory, or project inside your workspace is called a resource. The resources plugin provides an interface for accessing, navigating and manipulating resources within the workspace, but it can also be used;

  • When any project is closed or opened, and even imported or deleted;
  • When files are created, removed, copied, or moved within the directory structure;
  • When the directory structure is modified;
  • When building is about to happen and after it happens;

If you want a listener for any of these events, you’ll need to implement the IResourceChangeListener and register it in the workspace. Each “change event” affects many elements in the workspace, which can be analyzed using an implementation of IResourceDeltaVisitor (see this link to view some examples on how to do this) Debugging events DebuggingPlugin provides access to many features, including Debug Event Notifications. There are various debugging events you can hook up to by implementing the IDebugEventSetListener interface. These include: process launchdebugging session lifecycle (creation, suspension/resume, termination), etc. Some useful concepts to take into account when handling debugging events are:

  • Event source: This is the element associated with the event.  It can be a process that is not running in debugging-mode (IProcess), a debuggable process (IDebugTarget) or any thread being debugged within it (IThread);
  • Event kind: the type of event. The main kinds include: CREATE, TERMINATE (when debugging sessions are launched or finalized), SUSPEND and RESUME (when execution is suspended or resumed)

Windows and Parts changes I already defined a window and a part in Eclipse Terminology. You need to implement IWindowListener and IPartListener (respectively) in order to listen to these kinds of events.

  • Window events are useful when you want to be alerted when you switch your focus from the Eclipse Workbench to another program (windowActivated, windowDeactivated), or when you open or close a new window (windowOpen, windowClose).
  • Part events are useful when you gain or lose focus in any view or editor. This is especially useful if you want to track actions across the editor and file navigation.

Document and selection changes

  • Documents opened inside an editor part can be monitored for changes in their content. The interface to implement this is IDocumentListener. Depending on the editor type, you will need to handle changes differently. For Java code, there is a whole set of tools that  allows users to write, compile, test, debug, and edit the programs they have written: JDT (Java development tooling).
  • Selections can be entries in a viewer like a table or tree widget or pieces of text in an editor. Here is a great article that explores this topic some more. Each workbench window has an ISelectionService implementation which allows selections to be tracked by registering an ISelectionListener.

Getting to know what your plugin is doing Logging is sometimes an underestimated and postponed component on an application but it is an essential debugging tool when developing a plugin  (especially those which do lot of things in the background) . Fortunately, setting things up to log stuff is really simple. And you have the blessing of Eclipse’s Errors Log Viewer, which gives you some interesting features, such as filtering, sorting, searching and viewing stack traces in a very neat way. There are several ways to set up a logger for your plugin. One easy way to do it is:


 public LogManager() {
  Bundle bundle = FrameworkUtil.getBundle( this.getClass() );
  IEclipseContext context = EclipseContextFactory.getServiceContext(
                                                  bundle.getBundleContext());

  this.logger = ContextInjectionFactory.make( WorkbenchLogger.class, context );
 }

 public void logError(Throwable t, String msg) {
  logger.error(t, msg);
  }

 

You’ll need to add the following dependencies to your plugin:

  • org.eclipse.e4.core.services
  • org.eclipse.e4.core.contexts
  • org.eclipse.e4.ui.workbench

How do I deploy a plugin? There are several options to deploy your plugin locally or publicly. I feel like the best option, even for a local environment, is to create an update site. It can be more complex at the beginning, but you end up managing updates and versions the same way the end user would experience it. Also, it makes the actual public deployment much easier. Before Eclipse 3.4, plugins were distributed via the classic “Update Site”. P2 is the new update manager, which intends to optimize browsing speed and jar compression, and is backwards-compatible with the classic update manager. General steps to deploy a plugin within an update site are:

  • Create a Feature project and reference your plugin inside it.
  • Inside of the feature project, create a Category Definition. By default, the Eclipse update manager only shows the features inside a category, which is a good reason to always include a category in your exported features.
  • Finally export the feature in File -> Export… -> Deployable feature. In this wizard, you have the option to generate a p2 update site in the “options” tab. Also, don’t forget to check the “Categorize repository” option to include your category. This will export the site in the place you choose, either locally or in a running host.

Finally if you already have a classic update site running, and you want to migrate it to the new p2 schema, please read the following article.


Other useful resources Vogella Tutorials Eclipse Plugin Development FAQ Eclipse Platform Plug-in Developer Guide

  • Jesica Fera

    R&D Engineer

    Jesica discovered she wanted to be a Computer Engineer at the age of 13, with a basic knowledge of HTML, Visual Basic and Pascal. Since then, she loves exploring and learning new technologies, specially innovations in computational linguistics, data mining and AI. Besides computers, Jesica enjoys spending her time in other passions: figure skating,

Dejar un comentario