In the course of the conference, I’ve learned a great deal about Eclipse, its projects, Java, OSGi (EclipseCon was co-locating with the OSGi Community Event 2012), and programming in general, but also about open source communities, more precisely the Eclipse community.
In this post I’d like to share some of the stuff I’ve learned as well as some more general thoughts about my experiences at EclipseCon.
EclipseCon Europe 2012 had a massive problem: There were simply too many interesting talks going on at the same time! Of the 7 three-and-a-half hour tutorials the conference started with, I’d have wanted to do four. Every day was a constant checking of the schedule (via the conference app), and humming and hawing to myself about which talk I should attend. For example I’d have loved to hear about improving EMF models, putting P2 into practice, or agile documentation, but there just was something on at the same time that appeared more applicable, or seemed more important for my current situation / development stage of my software.
There were very very few talks which I regret having heard (I can think of only one to be honest, and I won’t say which because it was a very rare case of me already knowing close to 95% of what was said and hence a very individual problem), and thankfully the slides for the ones I missed will eventually be available from the EclipseCon website.
Below is a list of some definite highlights from the conference.
The Tycho tutorial (Jan Sievers, Tobias Oberlies)
Tycho is a set of Maven plugins which can be used to headless-build Eclipse plugins. It is an alternative to PDE builds, and in fact is now part of the Eclipse Common Build Infrastructure, an initiative to promote a best practice for building Eclipse software. I think it will pretty much completely replace PDE builds (not the tooling) as it is great technology. Once you’ve gone up that learning curve that is. At the time of writing, Tycho 0.16.0 has been released.
I was forced to start using Tycho a few months back (around the 0.13.0 release), and had a good old hard time. This was mainly because I was new to all this (Eclipse, plugins, OSGi, building, software development), and so was Tycho in a fashion. I banged my head against the wall of transitive dependencies hard, as I had to use a mavenized third-party model which pulled in all sorts of non-OSGi dependencies. I had to find a way around the issue (and learned how to build a P2 repository in the process), and kept using Tycho as build tool which offers great functionality such as automatic dependency resolution (from P2 sites, once you’re there), target platform support, automated builds for different target runtime environments (i.e., OSs), and products.
So I was really glad to find this tutorial on the schedule, as I had the feeling that Tycho is indeed great technology and I needed some diving into it to understand it for what it is. And the tutorial delivered beautifully. Okay, I’d have been able to find all the info on the web as well, but being taken by the hand and led through the different stages of setting up a complete, potentially multi-feature product built for different target platforms was ace, and perfectably suitable for me as a bloody beginner.
So if you’re looking for a starting point for Tycho, I will point you to the tutorial, and the tutorial only. Hey, it’s been written by the developers of the software themselves, so they should know how to work it, right? If you’re still having troubles, make sure to get on the Tycho users mailing list. Been there, done that, and it’s really helpful.
About committing to Eclipse (Benjamin Muskalla, Steffen Pingel)
At this stage of my ventures into programmer territory, I’d never dream of attempting to be an Eclipse committer. However, the talk about becoming an Eclipse committer was not only entertaining, it was inspiring, as it showed how open the Eclipse community really is. Should I ever feel fit enough to contribute to Eclipse, I know now how it’d work. And it’s easy! As easy as importing the project you want to contribute to into your workspace, doing your hack-o-magic, and then simply pushing your changes to the project git – where of course it’ll first be checked by the project’s Hudson build server, then reviewed by the project Gerrit, etc. pp.! A very inspiring talk, which I’ll hopefully get back on one day.
EMF fast forward (Cedric Brun)
This talk was perfect for me, as I had only just completed a two-day EMF training. EMF is the Eclipse Modelling Framework, and code generation facility, which makes it very (well, fairly) easy to translate any given business model into a Java implementation, complete with adapter classes, and even a basic model instance editor.
EMF is naturally surrounded by a multitude of satellite projects, plugging here or there into EMF to provide further functionality, wrappers, use cases, etc. This intense talk gave a quick – very quick – overview of available EMF-related frameworks as diverse as a model repository server and a model comparison framework. A smashing 15 projects in 25 minutes. Amongst which I’ve found at least one or two things I’ll leverage in my own development work.
Graphical editors everywhere (Frank Gerhardt)
An alternative GMF editor (Michael Golubev)
This talk was a dream come true, at the right time! As mentioned above, I had just completed an EMF training before travelling to EclipseCon, at which I had also given GMF (the Graphical Modelling Framework) a first spin, with a disappointing outcome: It took me ages to get a generated editor for a simple model to work! Now, GMF Tooling – or more precisely the GMF Dashboard and its results – should help you to create a graphical editor for your model with a few klicks. It does, but it doesn’t work out of the box (see forthcoming post). In short: I had a hard time, and I had almost given up on GMF completely.
And here comes the GMF Simple Map Editor! A graphical editor to define graphical editors! How cool is that? You simply create a diagram which defines how the editor will look and work, click generate, and that’s that. All the important stuff is packed into a simple tools palette (nodes, references, compartments, link mapping and the like). The demo that was shown looked very convincing, and I’m back among the believers now, thanks to it. I cannot wait to try it, and I’ll report back on it here.
> Seven languages for the JVM (XText)
> Building a tool based on EMF in 20 minutes (EMF Client Platform)
I had a really great time at the EclipseCon, but I also realized that in a way I am the odd one out with respect to the Eclipse community, at least that’s what I felt moving amongst it. Some of the reasons are the following.
- I’m new! Not only to Eclipse, but to the whole IT world in general (cf. the About page). I’m new to the etiquette (which I find very welcoming, and potentially friendly), and thus I wasn’t quite sure how to approach things and people. Some of the concepts have been fairly new, or indeed completely unknown to me. Also, I found it hard to talk about tech stuff, just because I haven’t done an awful lot and found I didn’t have an awful lot to contribute. I’m sure this will change in due course, and I hope that it’ll already feel different next year!
- I’m alone! Nothing to cry about, but I’m the only developer in my project, in fact the only person dedicated to anything related to software (and to be honest, that has its advantages!). I’m sure I wasn’t the only one there on her/his own account, but it certainly would’ve been easier to attend with other team members. Just people you know to bounce things off against, like things you’ve just learned. I didn’t, which was probably one of the reasons I didn’t attend the whole social events taking place. I know! I could’ve just talked to people more (in fact I have talked to people more than I thought I would), but you know how it is… Also, working in what I consider a niche “industry” (i.e., research level humanities) doesn’t really help in that regard. But hey, I’ve found out about at least one speaker who is also a linguist! Inspiring!
- I’m solo! See above, I’m the only developer in my team. This means that a lot of the interesting technology I’ve learned about at EclipseCon, such as Gerrit for example, isn’t really feasible for me to use at the moment. I’m not gonna review my own code, will I! Perhaps that’ll change as well, but I must say I quite enjoy being able to work fairly independently as well, so who knows.
To sum it up again, I had a great time and learned so many things! Thanks to the Eclipse Foundation for holding the conference. I hope I’ll be back next year (and staying at another hotel, something less early nineties maybe).
|If you found this post helpful, you may want to consider donating to help cover server costs.|