OS X Eclipse Launcher 2.0 released

When the better looking Eclipse Marketplace was announced earlier today I got a nice reminder that I had forgot to announce the new version of the OS X Eclipse Launcher. It’s a fairly popular tool, currently ranking at 168 of 804 products available at the marketplace, with between 170 and 359 installs each month for the past year. So I did try to be extra careful when I released the new version. Of course something broke and I had to do a respin, but it looks all good now and I have had no complaints as of late, so please go on and upgrade if you haven’t already.

Besides a rewrite of much of the code to make it more maintainable and better suited for supporting other platforms (no promises), I added one new feature, the Advanced… dialog. This allows you to specify a few more unusual arguments for starting a new Eclipse instance. The obvious one is which workspace to use, and also which JRE to use. I guess most will go for the latest and greatest here but it can be useful for testing your Eclipse installation on a different JRE.

There are also options for memory settings and remote debugging. The latter can come in handy when you discover what you think is a bug in your running Eclipse instance. You can then start a new instance and try it out. I have to admit I’ve only had need for that feature a couple of times myself, but that’s why it’s called the “advanced dialog”.

The last option is for disabling font size reduction – this can come in handy when you’re doing a demo and want the letters to be bigger without having to tweak the workspace preference settings.

One benefit in this approach is that you won’t have to edit the eclipse.ini file. That would invalidate the signature for the Eclipse Mac OS X application bundle and cause some trouble. There is a discussion in the Eclipse Bugzilla to change the location of eclipse.ini.

Thanks goes out to Marcel, Doug, Maarten and everyone that has provided bug reports. In the next version I’m planning to add support for the -clean option and maybe also persist the settings per workspace. What do you think?

NB! This plug-in is for OS X only. I see from the logs that users of other platforms try to install this. Don’t.

Easily switching between Java versions on OS X

If you’re a Java developer you’re probably familiar with the problems caused by sometimes having to switch between Java versions. At least on OS X there is no straightforward way of doing this. A typical use case for me these days is that Java 7 is used most of the time and once in a while I switch to Java 8 for playing with the new features.

So in order to make this easier I added a few aliases and functions to my .profile. The following allows you to easily switch between Java 6, 7 and 8 simply by issuing j6, j7 or j8 respectively on the command line. You may also use the command jls in order to list all available Java versions. The script is written for OS X, but can possibly be adapted to work on other operating systems.

Using Alfred 2 to run Maven scripts

Alfred is a quite popular productivity tool for OSX, however I’ve not cared much for it – until little over a month ago when Alfred 2 was released. The new version’s Power Pack includes a new feature called workflows which caught my attention. This allows you to define a keyword or keyboard shortcut that will run a set of actions of your choice.

I often build from source code using Maven, nearly all of these projects reside in my git folder. So usually it’s a matter of opening a terminal, navigating to the project and executing mvn clean package, then wait for the build to finish. Not a very time consuming process, but with Alfred’s workflow feature it can be improved upon. The Alfred manual is quite limited, so I decided to document the process here to serve as inspiration.

Above is the workflow with two bash scripts and two notifications.

The trick lies in the Script Filter box. It contains a bash script that finds all relevant pom-files and formats the list for use in Alfred. The script is shown below. Note that the expected output is in XML format:

When an item is selected the following script is executed:

The rest is simply a matter of handling the notifications.

Alfred in action

Now when I press Alt+SPACE followed by mvn and a qualifier I’m rewarded with a list of all my root pom-files residing in ~/git. Selecting an entry will execute mvn clean package in the associated folder, a notification will pop up informing me that the script is running. Another notification will be shown when the script is done and if it failed; the error log will be opened.


If you like this workflow you’ll find the file here. It can be easily imported by double clicking on it. Note that the file has been zipped because my crappy service provider is using IIS which thinks files ending with “.alfredworkflow” does not exist.

Opening multiple Eclipse instances on OS X (the easy way)

The one application instance only scheme of OS X can be an ache, especially when you do need to work on different workspaces simultaneously and the application at hand does not support it; such as Eclipse. The earliest mention of this problem with Eclipse I found in bug 139319; which was about starting multiple instances of Eclipse on OS X for exactly this purpose. Another related issue (bug 245339) was opened for the purpose of discussing a proper implementation of multi-workspace handling. The prior was closed as RESOLVED WONTFIX due to this.

Six years later Eclipse still cannot handle more than one workspace at a time – and OS X has become fairly popular. Thus several developers have had the same gripes and a few different solutions have come up:

These solutions are all a bit cumbersome and require labour; so I set about to write a small plugin that remedies this by adding a Open Workspace menu item just as in the original request. It will detect the application of the running Eclipse instance and start another in a fashion similar to the Switch Workspace command.

Now with all these Eclipse instances up and running I figured it would be a good idea if one would be able to tell them apart by taking a look at the icon; so the workspace name will show up in the icon badge if set (Preferences > General > Workspace).

That’s all there’s to it. You’ll find the source code at GitHub and the installer at the Eclipse Marketplace – or you can drag Drag to your running Eclipse workspace. into an running Eclipse instance.