Eclipse RCP is an incredibly useful platform but it’s often misunderstood. Many teams start using RCP because it seems like a quick way to create Java user interfaces, but it’s so much more than that.
Unfortunately there are few online resources that break down the technical and business benefits associated with RCP. I’ve decided to take a shot at it and I welcome your feedback. Check out What is RCP and why should I care?
I’m currently migrating an RCP application to Helios (3.6.1). I migrated over my target platform and fired up the export product wizard. The build completed successfully, but there was no executable in my output directory.
I spent a while chasing my tail trying to figure out if there was some hidden build error occurring, maybe a bad icon path or something. It finally occurred to me to actually examine the settings in the Product Configuration Editor, and I found that there is a checkbox labelled “The product includes native launcher artifacts” and it was not checked. Ugh.
What’s odd is that this checkbox existed in Eclipse 3.5 but it didn’t cause any problems until now. Anyway, I’m just throwing this out there to help any other poor souls who find themselves in this situation.
Now I can finally have lunch!
One of the things I love about being a trainer is that I get to visit and work with so many development teams. Every group of developers has their own chemistry, culture, skills and domain interests. Sometimes I think I’m learning as much as the teams I’m training.
As it happens, one of the teams I’ve enjoyed working with the most is looking for a full-time RCP/OSGi project lead. The company, EXTOL, is a small, successful ISV that creates B2B integration tools. I don’t do this too often, but I wanted to pass this on because I think it’s such a cool opportunity. What’s so cool about it, you ask?
So what’s the catch? Well, whether there’s a catch or not depends on what you’re looking for in your life at the moment. EXTOL is located in a small town (Pottsville) in the hills of eastern Pennsylvania. It’s a beautiful area with lots to do outdoors, a great place to raise a family and much more. It’s not for everyone, but I imagine it would be great for more than a few of the developers I’ve met.
If you’re interested, here’s a post on the EXTOL blog that goes into more detail. They’ll also have developers at EclipseCon, so feel free to introduce yourself to one of them (or me) if you’re there as well.
One of the talks I give most often is called “Why Java Modularity Matters”. This is my attempt to explain how modularity in general and OSGi in particular represent the next logical step in the evolution of software development. I’m actually giving this talk at the Madison Java Users Group tomorrow night, and if you’re in the area please feel free to stop by.
Anyway, I spent some time last week moving the presentation over to Prezi, which I’ve been interested in trying for a while. What I like about Prezi is that it allows you to convey structure and meaning in ways that are impossible with regular slideware.
If you’re interested in what this looks like, check out the presentation embedded below. It’s obviously not meant to convey a lot of information on it’s own, but you’ll get the general idea. And as always, I’d be interested to hear what you think.
I believe the next few years are going to be an extremely exciting and productive time for the Eclipse ecosystem. I say this not only because I’m an optimist at heart, but also because there are large scale forces pushing things in this direction.
The modular convergence
The way I see it, some of the large pieces of the software puzzle are converging on a single way of seeing the world. The reason for this convergence is the increasingly obvious benefits of modular software development. So what’s converging?
As these technologies continue to become more interrelated, the benefits of using them together is going to increase dramatically. I don’t think it’s too far-fetched to say that these technologies will coalesce to form something like a new new LAMP-style stack for Java development.
What does this mean for Eclipse developers?
It’s in the interest of the Eclipse community to promote this convergence in any way it can. As developers, we should be looking for ways to speed up the process and also take advantage of the resulting synergies. Specifically:
Speeding it up
In my opinion, the decision to make OSGi the foundation of the Eclipse ecosystem was one of the best decisions the Eclipse team has ever made. This decision has made it possible for Eclipse to participate in the convergence now taking place, but there’s more work to do. The actions we take now can slow the process down or speed it up. I say we take every opportunity to integrate with those who share an interest in modularity and OSGi. We’ll all be better off for it in the end.
I just spent some time updating the sample projects I provide to help Eclipse RCP developers get started with PDE Build. One of the main reasons for the update was to decouple the product configurations from specific feature versions, and I thought it was worth a post to talk about this.
What’s the problem?
By default, product configurations are hard-wired to specific feature versions. And if you decide to upgrade to a new version of the org.eclipse.rcp feature, for example, then your product configuration will break. You won’t be able to create valid run configurations based on your product and your builds will fail as well.
Luckily, we now get feedback in the Product Configuration Editor informing us that something is amiss.
So what can we do about this? Well one approach is to re-wire your product to the new version of the feature. You can do this by deleting and re-adding the feature, or you can also click the Properties button and modify the feature version manually. But this is a brittle approach, as you need to remember to update your configuration every time a feature version changes.
A better way
It’s now possible to decouple products from feature versions by replacing the feature version numbers with 0.0.0. In the future, a blank feature version will also be interpreted as 0.0.0 but as of Eclipse 3.5.1 the number must be added.
Also, there is a currently a defect in the Product Configuration Editor that results in a feature version entry of 0.0.0 being ignored. Of course, this won’t matter once blank versions are interpreted correctly, but for now it’s a problem. The solution is to open the product configuration file in a text or XML editor and change it manually.
The good news is that you only need to do this once. Your product will now accept the feature versions you supply in your target platform without complaint. Of course if you want to maintain the wiring between products and feature versions, by all means do that. But it’s nice to know we can decouple these pieces if we wish.
Of all the posts I’ve written on this blog, those on the Common Navigator Framework have been among the most popular. This is a little surprising to me, as I don’t hear CNF mentioned very frequently. My guess is that this framework is quietly becoming an essential part of Eclipse RCP.
Because of this, I’ve decided to write a set of posts discussing some of the CNF tips that I’ve found valuable over the years. And I think the best place to start is knowing when to use it. The Common Navigator Framework is complicated because it is trying to solve a complicated problem. It will only make your life easier if you’re using it for the purpose it’s designed for. So what is that purpose?
Modularity and extensibility
Well first, CNF was not created to make the development of navigators easier. If you have fairly normal navigator requirements in your application, CNF is probably not for you and you’ll save yourself a lot of headaches by omitting it.
Instead, CNF is designed to create navigators that support modularity and extensibility. With CNF, various OSGi bundles in your RCP application can contribute navigator content at runtime.
CNF allows your bundles to declaratively contribute content to a navigator, and this is not a simple exercise. As users of CNF, we need to wire together navigators and their content in sophisticated parent/child relationships, and then overlay on top of this structure a set of actions, filters, drag/drop handlers, etc.
Does it have to be so hard?
Some of you might be thinking modularity is supposed to help us to simplify our applications. Why does this stuff have to be so darned hard? Well this is true to a point. Modularity allows us to take information hiding to an entirely new level and to the extent that we can hide complexity, our applications become simpler.
But when dealing with modular UIs in particular, the difficultly arises when we work with the joints or pivot-points between modules. In these specific cases, there is always complexity because we have to define in detail how our modules relate to each other.
So the next time you’re struggling with a complex CNF extension point, ask yourself whether you really need this functionality. If you do, then embrace CNF for what it is: a complex solution to a complex problem.
What would I like for Christmas? Thanks for asking! Well, besides a Mac mini, what I’d really like is a simple update manager for Eclipse RCP applications.
Up to now, we’ve had two options for updating our applications: wiring in the Update Manager or coding something from scratch. The problem is that the Update Manager is overkill for most RCP apps and the API is fairly complicated.
What I would like to have is an alternative to the Update Manager that provides very basic update functionality. Call it Update Manager Lite, if you like. For those of you running OS X, what I’m thinking of is something like the Sparkle framework that many Mac applications use.
Would this be of use to anyone else? I’ve opened a Bugzilla entry suggesting this and comments would be appreciated.
Update: There’s already a Bugzilla entry for this feature, so the above entry has been marked as a dup. Please direct any comments you have to the original Bugzilla entry. Thanks to Susan McCourt for pointing me in the right direction!
People often ask me what’s so special about Eclipse RCP and what types of projects it’s useful for. Well here is one answer from EXTOL, a software company that is using Eclipse RCP as the foundation for it’s own products.
The short answer, which I like a lot, is:
Adopting Eclipse RCP gets us out of the framework business.
But please read the entire post for all the details. It’s well worth your time.
Well the results of the survey are in, and the clear favorite is the existing name: Eclipse RCP. While the original purpose of the survey was to create a short-list of names, I think the strong showing of the existing name means that the process should stop here. So long live Eclipse RCP!
For those of you interested in a summary of the results, 472 people took the survey (which is pretty good, I think). The top 5 name were:
There were also many write-in votes, some of which were kind of amusing:
On a more serious note, I’d like to thank everyone who took the survey and all of those who expressed their opinion both publicly and privately. One of the great things about open-source software is that we are able to make decisions as a community, and I think this process has been a good example of that.
Get information on private training options, pricing, availability and references.
There are still spots available in the next online RCP Quickstart course being held February 27 - 29.
Patrick Paulin is a software developer and trainer specializing in modular technologies such as OSGi and the Eclipse Rich Client Platform.
Patrick lives in Madison, Wisconsin with his wife and two daughters.
Email - patrick at modumind dot com
