Eclipse Neon is out. Time to give a long awaited feature a try again. It’s support for re-using the identify from ssh-agent running on my system within Eclipse. I want this primarily for the Eclipse Git integration.
As it turns out, the core support is part of Eclipse Neon. The SSH interface had been made extensible for additional identity discovery. The remaining missing piece is the actual code that bridges the ssh-agent connection into the Eclipse SSH interface (powered by JSch). The reason for this are – of course – legal issues. It would be great if those can be addressed and this can be shipped out of the box in Eclipse.
I forked the initial work from the JSch folks and made it consumable as an update site.
Please give it a try:
Here is another example of why I love working with open source software and its communities. Last Thursday, one of my team members reached out and asked for advice with regards to a build issue he was observing. We use Maven & Tycho at Tasktop for building almost all of our products. One of its unique features is automated stable versioning based on source code history and dependencies.
Turns out that there was a shortcoming in the implementation with regards to building an aggregated version based on component dependencies. After finding out, I opened a defect report, prepared a patch and posted to the mailing list for awareness and getting feedback on Friday. This took me less then an hour of my time. By Monday – only 72 hours later – the patch was accepted and merged into the main code base, unblocking my colleague.
- Discover the root cause.
- File defect report
- Prepare patch
- Communicate about change and collect feedback
- Cross fingers – or – hold thumbs.
In my opinion, the key criteria for such a change being successful is the patch size. Yes, I could have added configurability to the change and that would have increased the patch size. The larger a change is, the more time committers need to set aside for understanding and reviewing a change. It’s about the minimal viable solution – keeping things simple. Don’t overwhelm committers with your first change.
Well, and it pays off going to conferences and having a beer or two with project committers.
This is just a heads up that with Luna SR1 the formerly called “Eclipse Standard” package is no longer available. It has been renamed to “Eclipse IDE for Committers“.
For details/background please have a look at bug 441957.
The main reason for this change is because the name “Eclipse Standard” meant very different things for people so we decided on a name which clearly identifies the target audience of that package. It contains tools for Java and OSGi/Plug-in development and the source code of Eclipse itself. The history of that package is the Eclipse SDK which IMO shouldn’t be a recommended standard download of Eclipse.
What do you recommend for someone just got told to download “Eclipse”?
Eclipse IDE for Java Developers
Honestly, it has everything you need these days and it’s not to heavy. Even if you don’t need it for Java development I still recommend it as a better option than starting with a vanilla Eclipse Platform Runtime Binary.
But what if I just want an unbranded bare minimum Eclipse?
Here are the steps I suggest in order to build your own Eclipse base:
- Download an Platform Runtime Binary archive from http://download.eclipse.org/eclipse/downloads/
- Unzip to your local disc and start Eclipse
- Install the Eclipse Marketplace Client
- Got to Help → Install New Software…
- Select Work with: Luna – http://download.eclipse.org/releases/luna
- Check General Purpose Tools → Marketplace Client
- Click Next
- Review the installation details and click Next
- Accept the license and click Finish
- Restart Eclipse
Now you have an absolute bare minimum, unbranded Eclipse package built by yourself. From here it’s easy to install additional plug-ins from the Eclipse Marketplace (got to Help → Eclipse Marketplace…).
I recommend at least the following plug-ins:
The closer we get, the more exiting it is.
The conference is packed with lots of interesting content. I’m also looking forward to the new special days at EclipseCon which are new this year. Read more about EclipseCon and why you should attend on Ian Skerrett’s blog and also on the EclipseCon website.
FWIW, I’ll give two talks myself this year:
Unshackling Mylyn from the desktop
Grand Peninsula A – Tuesday, March 18, 2014 – 13:30 to 14:05
Andrew Eisenberg and myself been working on a prototype to extend Mylyn from the Eclipse IDE into web IDEs. While doing that, Andrew also came up with a few other interesting extensions using the same open web APIs to bring Mylyn into basically any other application. That’s pretty cool. There will be some slides in the beginning and then a full set of demos.
Gerrit reviews from within Eclipse
Grand Peninsula C – Tuesday, March 18, 2014 – 16:15 to 16:50
This one was originally proposed by Ericsson but the speaker isn’t able to attend EclipseCon. However, I was involved in the work that happened last year from the beginning and it’s now available in Mylyn Reviews. With the Gerrit dashboard now being available within Eclipse it’s no longer necessary to switch between the web and Eclipse back and forth when doing code reviews.
For me personally, it really is like a big family anniversary. It will be my ninth EclipseCon in North America and I’m pretty sure it’s not getting any less interesting then my first one. I also look forward to the Hyatt, which I never been at before.
See you all there on Sunday and throughout the whole week!
The Eclipse Bundle Recipes project (EBR) was created with the intention to develop and host a technology and recipes for creating OSGi bundles out of regular non-OSGi Java libraries. Unfortunately, not a lot has happened after it’s creation. Frankly, as the Git repository and the history unveils, it has been just a code drop of the SpringSource Enterprise Bundle Repository recipes. I’m here to change that!
As an Orbit committer, it’s has been my pleasure to convert Java libraries to OSGi for quite some time now. If you know how Orbit bundles are created, you know it’s an exercise. Thus, I also have a high motivation for the Eclipse EBR project to be successful. Last week was one of those where I looked at upgrading a few of the Orbit bundles I’m maintaining. Turns out, the libraries are actually quite active and – as every good OS project does these days – they also release very frequently. That’s really turning into a boring exercise. Thus, I decided to craft together a process that would simplify things for me.
The result is very promising. With just one nice little Maven plug-in I created, a small Maven POM and an OSGi BND descriptor file I’m now able to consume the libraries directly from Maven central (or whatever Maven repo they come from), push them through a filtering step which may remove or add files, generate the OSGi manifest headers, add p2 metadata information and deploy them back into a Maven repository (eg. a local one). Then, in a second step, I’ll let Tycho run and it creates a p2 repository where the bundles are published together with a source bundle containing the library source code. Done.
Over the next few days I’m hoping to make that available in the EBR Git repository.
For the time being I pushed it to Github*. I first need to review the dependencies and push them through the Eclipse.org IP process. Once that is done, we should have a pretty neat solution for EBR. However, remember that EBR will only host and distribute the recipes, not the actual libraries. You have to generate them yourself.
For Eclipse projects, this is where Orbit comes back into the game. Orbit can take and run the recipes of all IP approved libraries from EBR (or create its own) and publish the bundles as today in p2 repositories.
: Update, Feb. 28
I pushed the Maven plug-in as well as the first recipes to the Eclipse Git repository. You can browse them at
2nd Update, July 8 2015
The EBR project is available at github.com/eclipse/ebr. Submit pull requests for all the recipes you create!