Getting To Grips With the Equinox Console

When developing Eclipse RCP applications, sometimes you’ll find that your plug-in’s capabilities don’t seem to available. The Equinox OSGi console is one of the most useful tools to inspect the state of all the plug-ins in a running application. This article gives a brief introduction to the console, and how it can be used to help with your development of an OSGi based system.

To make the console available, just use the -console parameter in your run configuration. If you want to see the console for an “installed” Eclipse instance, you can just add -console to the list of parameters for running Eclipse (e.g. eclipse.exe -console). Having done that you’ll see osgi> appear in the console output, similar to an MS-DOS window.

The following is a list of commands that can be used in the osgi console:

  • help
    Lists all available commands.

  • ss
    Provides a list of all the plug-ins and their current status. If you provide a string after ss, it will list all bundles containing that name. For example, if I used ss logging I would be presented with a list of plug-ins that contain logging in their name. ss here stands for short status.
  • start
    Starts up a plug-in. You can either pass through the full name of the plug-in to this command, or else you can use the symbolic id, as displayed from the previous ss command.
  • stop
    Stops a plug-in. Just like the start command, you can either pass through the full name of the plug-in or the symbolic id.
  • install
    Paired with a URL , this installs the plug-in that the URL refers to into your system. There is also an updatecommand, that allows you to update a plug-in using a URL.
  • uninstall
    This command takes the symbolic id of a plug-in and uninstalls it from your running system
  • diag
    Using the symbolic id, or the plug-in name, this command shows all resolution problems for a particular plug-in.

  • active
    Lists all the active plug-ins in the running system.

So when you have an issue with your plug-in:

  • Make sure it’s on the list of bundles, using the ss command. Or if you expect the plug-in to be running, use the activecommand.
  • Using the id of your plug-in (usually easier than typing in the full name) check that the status of your plug-in is  ACTIVE. If not maybe you need to force the plug-in to start up using the start command.

Once you become familiar with the OSGi console, it becomes a very powerful utility for investigating the overall status of your OSGi based application.

Effective Teamworking With Eclipse: Highlighting Local Changes

Eclipse can make your life really easy when it comes to working with version control systems. Over the next few articles, I’ll be sharing some of the tips that I’ve picked up while using Eclipse (with CVS).  When you make changes in your local workspace, the default decoration is a  ‘>’ before the change, up to project level.  This is fine, but isn’t particularly obvious when scanning through your workspace.

You can actually make these changes really stand out using some simple changes to your preferences.  You’ll find the preferences on by navigating to Window/Preferences/Team/CVS/Label Decorations

On the Text Decorations tab you can change the default change flags:

On the general tab, you can change the colors and fonts of anything that has changed locally.
First, click through to the Colors & Fonts page.  This part of the preferences dialog allows you to customize the colors that are used.

Now, when you enable font and color decorations, your changes will be much more obvious:

Hopefully you’ll find this as useful as I did. Eclipse is my everyday IDE, but I’m sure that similar settings exist in other Java IDEs. If so, please share how to access those capabilities with a response (or another article).

Effective Teamworking With Eclipse: Change Sets

The last two days I have been looking at various ways that Eclipse assists developers when working with version control systems. First, we talked about highlighting local changes, then we discussed how to automatically synchronize with the version control system. Todays tip deals with Change Sets, which is themost useful feature in Eclipse for seeing real context behind changes in version control.

To view change sets, you can synchronize as normal but by making a few changes to your Synchronize view, everything looks brighter.

First, go to the preferences dialog in the synchronize view and ensure change sets is visible for models:

Next, choose the drop down list on the third button in the view’s toolbar to choose change sets as your view:


Once this is chosen you’ll see all changes in the batches that they were committed in. The name of each change set will be whatever the author used as the commit comment, or if they explicitly create their own change set, it will use the change set title.


You can create your own change set by clicking on the changes in the synchronize view and choosing Add To> New Change Set.

Of course the neatest way of managing your change sets would be to use Mylyn, but we’ll cover that in another article.

Using the change sets view while synchronizing automatically makes viewing the differences between your local workspace and CVS simple.

Reduce Workspace Noise in Eclipse Using Working Sets

Last week I wrotefew articles on how Eclipse can assist when working in team environments. Today, I have another Eclipse related tip – this time to do with how you organise your local workspace. Developers will typically have a number of projects in their workspace at any one time. If you’re working with a plug-in/OSGi system, the number of projects can be huge.

For example, this is one of my workspaces:

So one of the best ways to reduce the workspace noise is to move to working sets. Typically your projects can be grouped into categories, whether that’s functional or feature related. Choosing Working Sets as your package explorer view, you can group your projects into these sets.

And using the Configure Working Sets option, you can even choose which working sets to display at any time.

From this view you can edit working sets to choose what projects to include. You can also right click on a project at any time and using the Assign Working Sets menu option, send it to one (or many) working sets.

By default, any project without a working set appears in the predefined “Other Projects” working set. Another benefit of this new organisation is that you can “Go Into” any working set (second option in the right click of a working set) to drill down into that working set only:

The new project/import project wizards even allow you to assign the new addition to your workspace to a working set immediately.

It’s all pretty simple, but when I first found this feature it really helped me clear up how I worked. Hopefully it’s useful to you too.

Customizing Eclipse: Setting Up Shortcuts

If you’re using Eclipse as your IDE every day, you’ve probably got certain tasks that you do regularly such as getting projects from version control or writing unit tests, as well as normal coding tasks. This tip shows how you can customize what shows up on your File/New menu for a certain perspective. Some of the commands that you use might be buried under the File/New/Other.. menu. This brings them up a level.

To do this, go to Customize Perspective from the Window menu in Eclipse, while in the perspective where you want the changes to apply.

Here, you will see a number of options that you can add to the New menu. Note that you can also customize shortcuts for the Show View and Open Perspective menus from here.

Just select the items that you want to appear. In the above example, I’ve included the JUnit shortcuts.

Now when I use the File/New menu, these options will be easily accessible:

It’s a pretty simple thing to do, but it might save you a little bit of time.