EclipseCon North America 2016 Retrospective

It’s been almost a month since EclipseCon North America 2016 closed, but I figured it is not too late to write a short retrospective, so here goes.

EclipseCon is a series of conferences arranged by the Eclipse Foundation in the USA, France and Germany. In addition we have Eclipse Summit India, which is a new conference this year. The conferences in the USA and France are the smaller ones with almost half the number of visitors compared to the one in Germany. All are stretched over four days, but have different focus.

For many, Eclipse is a Java IDE, but in reality Eclipse is an organization that hosts a number of activities. For example the Science Working Group which has teamed up to build scientific software and the IoT Group which does the same thing for the Internet of things.

This year’s EclipseCon North America (ECNA) was in Reston, Virginia from the 7th to the 10th of March. The first day was mostly tutorials, one before lunch and one after. I attended “The ins and outs of high-performance modeling and simulation with Eclipse” and the members meeting after lunch. This is a yearly thing where the organization’s financials and member numbers are presented. We also got an update on the FEEP-program where the foundation is financing development and improvements of core Eclipse components. This is a fairly new initiative to improve the platform in areas where the members are not focussing. We were also told that there are now 302 projects hosted and the number of member organizations is close to 300 – both numbers are increasing slowly.

The keynote on Tuesday was given by Tyler Jewell from Codenvy which amongst other things announce the Eclipse Che release. This is a neat browser based IDE with support for Java, Node.js, PHP and more. The presentation was supplemented by representatives from RedHat and Microsoft. The latter announced that they are joining the Eclipse Foundation as solution provider members.

Tuesday I was attending several good talks, I’d like to mention Johan Stokking from the The Things Network: These people have created (crowdsourced) a network of LoRaWAN portals around Amsterdam which lets the little things of the Internet connect in a cheap and safe way. If you’re into IoT you should definitely check this out.

New this year at ECNA was a “Science Track” with presentations related to the projects in the Eclipse Science Working Group. EclipseCon France started this track in 2015 and we also had one at EclipseCon Europe later in 2015. This time the number of talks was nearly doubled – to thirteen. There was a lot exiting talks in this track and I think it is clear that the Science Working Group is maturing – only a couple of years after it was started.

Wednesday got a unexpected start. The keynote speaker for Thursday called in sick and someone should replace her. Could the Science Working Group step up? We said yes without actually thinking about it, but as it turned out that was not a problem. Everyone helped out and I think we pulled off a decent keynote. I’ve certainly seen my share of worse ones.

This slideshow requires JavaScript.

In the evening on the same day we arranged the yearly general meeting in the Science Working Group (SWG). At the end of this we had presentations from the Canadian Space Agency that showed Apogy and Halliburton that demonstrated software for analyzing geology in relation to oil-and gas-extraction. Yours truly was re-elected as a secretary for the SWG steering committee and Jay Billings was reelected as leader for the committee.

Thursday it was my turn to do a presentation about “Mylyn Docs and how it can be a powerful tool“. The room was nearly full, so I was pleased although I did not get as many questions as expected. I was approached later on by several of the attendees so I take this as an indication that others also think working on documentation generation tools can be fun 😄. The source code with examples is on GitHub.

I should add that even after ten years of going to Eclipse Conferences I still think they are awesome. You get to meet interesting and smart people, learn new things and inspire others. Some things are the same old, while others are in the forefront of technology and new developments. The conferences are pretty intense as there is a lot going on over the four days – so doing a writeup like this is not quite doing them justice. If you don’t believe me, come see for yourself.

The next Eclipse-conference is EclipseCon France in June and we also have one event here in Trondheim, The Eclipse DemoCamp Trondheim in August.

See you there…

Call for papers, EclipseCon Europe 2015

Time flies when you’re having fun! EclipseCon France has just finished and it’s already time to plan for EclipseCon Europe 2015 in November. The call for papers is out, and you should not miss the chance to present at the tenth European Eclipse Conference. It’s a great opportunity to meet people and show off your technology.

The first Eclipse Summit Europe was convened in 2006 – a two day event in the charming town of Esslingen am Neckar just south of Stuttgart. Since then the conference has been at the Forum am Schlosspark in Ludwigsburg, also in the Stuttgart region. In 2011, for the tenth anniversary of Eclipse, the name was changed to EclipseCon Europe. The number of attendees, from around 30 different countries, have been growning steadily to about 600 in 2014. It’s now a three day event, well packed with activities and interesting talks. This year we’re even adding a science track for talks about the tools on the scientific workbench.

The deadline for EclipseCon Europe submissions is the 31. of July, so you have a whole month to work on your abstract!

You may also consider submitting a paper for the Trondheim Eclipse Mars DemoCamp in August. We have space for a couple more talks and it’s a good opportunity to try your talk on an Eclipse-savvy audience before the real deal at EclipseCon.

See you there!

Timekeeper for Eclipse released

The "Timekeeper for Eclipse" workweek view.

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

Maven Run

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 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.