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.

Unit testing Eclipse RCP applications

There are different notions of what an unit test actually is. While most will agree that it is a test that verifies a pretty small part of a software system, we don’t all agree on how big a part this is. Personally I want a unit test to cover as little as possible. This, I think, makes the tests more manageable and makes it more likely that we can execute them with a minimum of fuss and in the shortest time possible. The following sums it up:

A unit test is an automated piece of code that invokes the smallest testable part of a system and then checks a single assumption about the behavior of that part.

Because a these tests verifies such a small part of the system I think a unit test should be in the same bundle as the code it is testing. And since it is only testing code contained withing the same bundle, it won’t need any extra dependencies (except for Junit). Setting this up when using the traditional PDE Build cannot be easily done without including test code in deployed bundles. As a workaround you can create a plug-in fragment to host unit tests. That will work, but causes other complications. Apart from the hassle of managing an extra bundle, you will for example not be able to verify platform specific code hosted in a fragment using tests hosted in another fragment. You’ll want these tests to be in the platform specific fragment.

Hosting the tests in the same bundle as the tested code is not very straightforward when using Tycho and Maven either, but it is possible and well worth the effort. I’d like to propose a solution.

The first thing we’ll do is to set up the project in the Eclipse IDE. As you may know, Maven by default expects a root src folder with main and test subfolders. This layout is not commonly found in Eclipse bundles, nor is it default when creating new plug-ins. Also we don’t want the eclipse-plugin packaged bundles to include the tests. So that’s why I elected to add another src-test folder instead. Do as follows:

  1. Add a new source folder for tests, src-test
  2. Exclude this in build.properties by adding src.excludes = src-test/
  3. Add Junit libraries to the build path. Go to Project properties > Java Build Path > Libraries. Add “Junit 4”.

Unit tests

Unit tests now go in the src-test folder of the bundle. And because the dependecy to Junit 4 is added to project properties and not the MANIFEST.MF, we can compile and run the test code without the org.junit bundle ending up in the product. To hone you TDD skills you may now consider installing a tool for continusly running your unit tests. Infinitest is a good candidate.


Tycho will not automatically pick up these tests so we need to add some configuration in the pom.xml to let Maven know that we have these:

  1. The test source folder must be specified (src-test).
  2. The Maven compiler plug-in must be bound to the test-compile phase so the tests gets compiled.
  3. The Maven Surefire plug-in must be activated

And that’s all there’s to it. Now, integration tests and UI tests should go into separate bundles packaged as eclipse-test-plugin as before. These will be executed in the Maven integration-test phase. Well after the test phase in which these tests will execute. So if there are any issues uncovered by the unit tests, the build will fail as soon as possible.


EPUB tools in Mylyn 3.13

I realized it’s been quite a while since I wrote about building electronic books using the tools in Mylyn Docs and figured it is about time I published an update. It’s been pretty quiet around this project. I’ve had a couple of e-mails with request for support and a few bugs reported, most by myself. So I decided to have a look at the download numbers. The Mylyn Docs EPUB tools have not been part of the Eclipse release trains, so anyone installing the feature must be doing so actively. There was a total of 7899 downloads from the Mylyn 3.12 release (June 2014) and so far 2304 downloads from the latest 3.13 release (September 2014) — which I figure is not bad at all. I guess the silence is because there is little trouble with it. Anyway, a few bugs has been fixed and some new features has been added to simplify EPUB building. Here’s the summary.

Earlier this year I did some major changes in order to future proof the code and make ready for EPUB 3 support. In short the following was done:

  • OPSPublication was moved to Publication in order to make sense for both EPUB 2 and 3.
  • OPS2Publication was moved to OPSPublication as there is no OPS in EPUB 3.
  • EPUB2Bean was moved to public API and renamed to PublicationProxy.
  • Public API was cleaned up and documentation added where lacking.

These were API breaking changes and the version number was bumped to 2.0.0.

In addition MIME type detection was been greatly improved through the use of Apache Tika. In practice this does not matter much for EPUB 2 publications as the allowed content types are quite limited. But my dodgy content detection code from earlier could be removed and this implementation is much more trustworthy.

The biggest improvement came with the 3.13 release of Mylyn. It is now possible to simply specify an Eclipse table of contents file as a source for content declaration. This allows you to single source this part of the manifest. We use this mechanism at a project I’m working on and it has turned out to be real timesaver. Here’s another example:

This is the actual Ant code used to build the Mylyn Docs EPUB tools user guide as a book at the same time as the Eclipse Help is built. The Ant script is referenced in the pom-file and called by Maven during the generate-sources phase. You’ll find a mirror of the code at GitHub if you’d like a closer look. An example of the resulting book can be downloaded from http://blog.resheim.net/files/Building_EPUBs_with_Eclipse.epub

I’m planning to add support for EPUB 3, but so far there is no real need and nobody has requested it. However one feature I’ll probably will add, is to the wiki markup to HTML generation mechanism of Mylyn Docs. At the project just mentioned we use a lot of LaTeX math in our Markdown documents, so we would like these to be converted to MathML when the HTML is generated. Many reading systems are capable of displaying MathML properly, it is an required part of implementing EPUB 2 support. So we would be able to create e-books with beautifully rendered math straight from wiki markup.

…until next time.

Heavenly bodies icons for Eclipse

It became tiresome not being able to see which version of Eclipse my OS X Dock icons leads to, so I quickly put together one for Luna and another for Mars using images picked from Wikipedia. On OS X one can easily replace an application icon by opening the application information dialog and simply dragging the new icon on top of the old. Note that because the Eclipse launcher will actually replace the icon once it has started, you also need to open the Eclipse.app folder and replace the file in Eclipse.app/Contents/Resources.

Feel free to use the icons, they’re at https://github.com/turesheim/eclipse-icons

I have no idea on how to do this on Linux and Windows but you can probably figure it out. If you do, please add the new versions to the git repository for others to enjoy.

Setting up a local p2 mirror for Tycho

Now that EclipseCon Europe is nearing, I decided to do some preparations. As most years some time will be spent on hacking, and this year is no exception especially with regards to the Science Working Group coding session at the Unconference.

These days many Eclipse based projects use Maven and Tycho for building. All my hobby projects are also using this technology. It’s quite nice, but a common problem is having to download artifacts when the network is bad or unavailable. From experience this happens a lot at EclipseCon Europe so I’m planning to avoid it. You can resolve this altogether by setting up a local artifact manager such as Nexus. Nexus supports both Maven and p2 repositories so if you have one of those you won’t need these instructions. I’ve set up Archiva on my NAS and rely on the local cache when the network is unavailable. However this only supports Maven artifacts and when building Eclipse based applications one also need the various dependencies. I’ve resolved this by creating local mirrors of the p2 repositories I often use, and instructed Maven to utilize these.

First you need a running HTTP daemon such as Apache on your system. I’m on OS X so I’m all set – just had to enable user directories after updating to Yosemite. Next you have to create the mirrors. This is done by calling the Eclipse mirror application. Once for the metadata and again for the artifacts. Replace path to eclipse and destination as appropriate.

If you’re on OS X and has upgraded to Eclipse 4.5 the patch to the eclipse executable is different: Eclipse.app/Contents/MacOS/eclipse

Be prepared to wait quite a while for the last one to finish. If you want to speed it up you should try to find a faster mirror of the p2 repository. I repeated the process for SWTBot. Next I altered ~/.m2/settings.xml so it looks like this:

Once again, adjust the URL to suit your needs. Next it’s just a matter of making sure that the repositories referenced in the *.pom files match the mirrors. Just make sure that the identifiers are the same as the mirrorOf attribute in the configuration file or the mirrors will not be used.

That’s it. Happy coding!