It’s been over nine months since my visit to EclipseCon North America 2016. Thanks to THTH, I had the wonderful opportunity to attend this conference. Actually it was the first time anyone from the Simantics development group has attended an EclipseCon conference. In hindsight I can say it was definitely about time to do so!
Personally the conference was a really educational experience and based on the lessons learned we intend to change some aspects of our infrastructure - hopefully for the better. The following sections are a short recap of the presentations I attended and found noteworthy from my point of view.
Eclipse 4.x lessons learned Until the very beginning of 2016 Simantics SDK was still based on Eclipse 3.7.1. We were quite late to jump on the Eclipse 4 train because there just wasn’t enough incentive to do it for a long time. The best (or worst) trigger to do so was the fact that Windows 8 and later versions were not properly supported by 3.7.1 anymore and we had to start doing too many tricks to get products working there. For example, the 3.7.1 version of the Equinox launcher seems to have a bug that causes the process to crash when an application is restarted using the specific restart exit code and there was no workaround for this. Another major problem was that we could not move to Java 8 as long as we built on top of 3.x releases.
So, finally in January 2016 we released versions that were based on Eclipse Mars 4.5.1. Of course there were still some rough edges but through much trial and error we’d gotten it to work well enough. However we were a bit unclear on what we should do with all the E4 mechanisms like Eclipse contexts, injection and all the related annotations. We didn’t really understand if it was possible for us to move to a pure E4 application or not. Luckily EclipseCon tutorials and sessions answered this question quite well. This session on E4 migration was particularly useful.
The most important message from that session was that the Eclipse 3.x Application Platform (or E3.xAP for short) is not going anywhere. The fact that they decided to call it the “E3.x compatibility layer” in E4 gave many people the idea that it is something temporary and at some point this layer will probably be removed - what do we do then? No need for panic. For the foreseeable future or at least as long as E4 doesn’t provide clear replacements for the most important features in the E3.xAP, the “compatibility layer” is not going anywhere. For one, E4 doesn’t provide any replacement for E3.x editor parts. As long as your application needs to use the concept of editors, you’re best off still using the compatibility layer. These days it is actually possible to combine both worlds, i.e. still use the good old editors but also start using the context injection mechanisms provided by E4.
Related sessions:
https://www.eclipsecon.org/na2016/session/tips-and-tricks-your-eclipse-4-migration https://www.eclipsecon.org/na2016/session/good-bad-ugly-review-eclipse-4-its-apis-and-architecture
Version Control - Git, Gerrit, EGerrit and Git LFS For me personally Git and Gerrit were quite a hot topic at the conference since at the time I had only spent very little time working with Git and zero time working with Gerrit. I didn’t really know what Gerrit was until it was shown to me at the conference through hallway discussions. I didn’t immediately understand what it did and how it worked but that’s usually the case with new tools. You simply have to get your hands dirty to understand it.
The session Practical workflows with Git LFS (Large File Support) (https://www.eclipsecon.org/na2016/session/practical-workflows-git-lfs) provides very informative material on why exactly Git has problems with large binary data and what has been done about it. We have plenty of cases where we simply have to put large binary files in repositories and Git LFS is really the only proper solution to handling these cases satisfactorily. What it essentially does is replace binary blobs with pointers to binary blobs in the cloned repository. Instead of having git clone fetch every binary blob version every put into a repository, git lfs clone will then merely clone the required version of the binary blobs and the rest is left on the remote server. One can say that it effectively turns the normally fully distributed Git back into a semi-centralized solution where the origin server is still needed to gain access to all the data in the repository. But hey, that’s just the price we have to pay for not having to clone every single bit of those nasty binary blobs. The talk also mentions the BFG Repo Cleaner tool which works very well!
Gerrit + Eclipse = EGerrit talk was also an interesting one. Having the Gerrit review functionality directly in the Eclipse IDE is maybe not that big a deal since the Gerrit web UI is really good once you’re familiar with it. The main perk is that you can review the code in the very same environment where you develop it so it is perhaps a bit easier to relate the code to your development environment. These features are highly reminiscent of Eclipse Mylyn, only this time for Gerrit integration.
Since the conference we’ve managed to put Git and Gerrit to good use which is the topic of another post later on.
Builds: From Buckminster to Maven+Tycho There was no talk directly on this subject but I ran into it after attending From code patch to Jar file: close the loop with Eclipse Common Build. The Eclipse Common Build Infrastructure relies mainly on Maven and Tycho these days. Although changing tools like clothes is not really my cup of tea at all, in the end it boils down to weighing the potential benefits and the time and effort required to switch.
At the time of writing this, I can already say we’ve successfully switched some of our projects from Buckminster to Tycho. We’ll get more into that in later posts.
Oomph The Oomph project provides many things and is perhaps best explained on its own project site. However, from our perspective the most enticing thing was what is built out of it, i.e. the Eclipse Installer.
When a developer tries to get started with Simantics development, first he has to go through these instructions: http://dev.simantics.org/index.php/Quick_Development_Environment_Setup. One must minimally install the Simantics graph compiler plug-in and a Subversion client plug-in to get cranking. Although it hasn’t been a big problem in the most recent years anymore, in the early days of Simantics development developers often had troubles just getting the basic IDE installation working correctly. Clearly this is something that could and should be done with Oomph, i.e. to automate these recurrring IDE installation and configuration tasks by modelling them with Oomph.
We have tried this a couple of times throughout this year without success. Regardless, I think we will keep trying to work it out in the future. Naturally we want to automate things instead of just documenting them.
Testing There was one particularly interesting talk on automated testing: Winning the battle against automated testing. It had very good points on what are the usual problems with testing and how to properly set up automated continuous testing. Well worth a read.
Other Cool Stuff One particular noteworthy presentation stuck in my mind because it will provide genuine usability improvements through performance improvements. That presentation was Faster index for Java, or CDT pays its debt to JDT. They have inspected that most IDE UI freezes are caused by JDT and particularly its current index implementation. This work results in massive performance gains for JDT indexing which will result in much more responsive JDT UI overall experience. Presently it is still work in progress but they were hoping to make the new indexer the default for Eclipse 4.7 Oxygen.
Another interesting talk was Succeed with Eclipse: Large Scale. This is a really interesting case on the many problems encountered working with a very large application in Eclipse. I am grateful to the presenter for many fun discussions and teaching me some new things about Eclipse!
I’m also very happy that I got some cool Eclipse-related tips through hallway discussions. It’s always worth it talking to people! Thanks to this I use the CTRL+3 key binding a lot nowadays to find pretty much anything in my IDE. Also, I didn’t know that I can import Eclipse plug-ins directly from git repositories through the Target Platform State view by using the Import As context sub-menu. This is absolutely the easiest way to getting your hands on IDE codebase and to fix and test your changes to the code in your own application.
Conclusion Overall the conference contained a lot of interesting tutorials, keynotes and talk sessions. There was way more interesting material than one person can attend. In hindsight I should have attended the following sessions instead of the ones I went to:
Tutorial: Oomph: Eclipse the Way You Want It This would have been interesting because we’ve tried employing Oomph for basic IDE deployment during the year without much success. Git Journey from Mars to Neon Might have helped us get on the Git bandwagon a bit faster to actually see it in action. Rapid Integration of Scientific Software with Eclipse ICE Scientific Simulation with Eclipse - From Zero Code to Running on Lots of Cores in 10 Minutes Both are close to our domain, nice work