Timekeeper for Eclipse released

For the past two-three months I’ve been building a timekeeper plug-in for Eclipse to keep track of how much time I spend on each task and project. What started out as an experiment in using the latest Java 8 APIs, specifically DateTime and Streams, has at least for me become a useful tool. There are a few more features I’d like to add before I consider it done, but since it’s been working just fine for quite a while I decided to share. Feel free to try it out and let me know if there are any issues using the GitHub tracker. Note that you need to run Eclipse on Java 1.8 and that Mylyn Tasks also must be installed.

Whenever a task is activated in Mylyn it will automatically show up in the Workweek view with a bold label, and the amount of time the task is active per day will be tracked. However if you go AFK for more than one minute the time will not be automatically added – when you’re back you will be asked how to handle this. The time can be manually edited by clicking into a cell.

There is built in support for GitHub, JIRA and Bugzilla task repositories, however other repository types should also work. Tasks from GitHub are grouped by the name of the first query they appear in. Tasks from Bugzilla repositories are grouped by the “product”. Which field to use for JIRA is undefined so one must be selected. This can be done by right clicking on a task and selecting a field from the Set Grouping Field… menu.

Note that the timekeeping data are stored in the task repository so they follow your workspace. If the workspace is lost, so is the timekeeping data.

See the GitHub page for more details and the code. The installer can be found at the Eclipse Marketplace – or you can drag  into an running Eclipse instance.

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.