I’ve been thinking a lot lately about what defines an Eclipse project? Not in the literal sense (a project hosted at eclipse.org that follows the EDP), but rather, what technical qualities do all Eclipse projects share.

Years ago the answer was simple, extensible IDEs. More recently Eclipse was defined as a tooling platform (for everything and nothing in particular), but when you start to look at where Eclipse projects are being used (Eclipse RT and modelling projects in particular), you realize that ‘a tooling platform’ doesn’t begin cover the spectrum.

Even eclipse.org has got out of the business of defining Eclipse. And while defining ‘Eclipse’ might not even be possible, there are a few technical qualities that all Eclipse projects share:

1. OSGi Based (most projects produce OSGi bundles)
2. A strong commitment to API
3. Meaningful versions

It’s the last two points that I want to focus on here.

Most Eclipse projects defined their versions based on API. We don’t use version sequences like 3.0, 3.1, 95, 2000, XP, 7. Instead, Eclipse projects define their versions such that a change in a version number indicates API compatibility (or incompatibility). There was an excellent tutorial at EclipseCon on this topic, and I believe that the connection between API and versioning is so important that it should be part of the undergraduate curriculum for software engineering.   Like many software engineering activities, manging the relationship between your API and version number is challenging, but it can be aided through tool support. Lucky for us there is an entire Eclipse component dedicated to API tooling.

As we approach the Helios release, I’ve been counting down the Top 10 Features I’m most excited about. Number 8 on my list is Improved API tooling support.

API tooling has been included in Eclipse for a number of years now. When you enable API tooling as consumer of API, you can identify when you are using methods you shouldn’t be:

Producers of APIs can use the tooling to help identify when they have ‘broken’ API:

While these features have been around for a number of years now, there are some noteworthy additions to API tooling. There is now a launch configuration which can be used to track API usage and generate HTML reports. This allows producers (and consumers) to see who is accessing non-API packages / classes / methods:

While this is valuable information, most most exciting advancements of API tooling is the new Migration Report. Using the migration reports we can determine if our bundle(s) can be (easily) migrated to a new version. For example, if the API producer decided to change the signature of their apiMethod to include a new parameter (and they properly released version 2.0 of their bundle), we could run the migration report and as a consumer.  Doing so would uncover any migration issues. In particular, on Line 10 in the doSomething method, we invoke a method that no longer exists.

More information on the migration tasks can be found on the Eclipse help system.  Thanks to Chris Aniszczyk, Michael Rennie, Darin Wright and Olivier Thomann for this work.

Note:  If I missed someone in the kudos, please let me know. I do my best to track down who worked on each feature .

Tags: helios

Yesterday I asked you to think about high-quality software that has been consistently delivered on-time for eight straight years. To make this quiz more challenging, this software should be installed on millions of users’ desktops.

As we approach the next major release of Eclipse — dubbed Helios — I’m counting down the top 10 features I’m most excited about. Yesterday’s feature was the improvements to Resources. Number 9 on my list comes to us courtesy of the Plug-in Development Team: Feature based targets and launch configurations.

I’ve read many articles over the years that compare IDEs. These articles often critique the support for particular programming languages. For example, some IDEs support Closure, or Haskel better than others — and if you use these languages then you should use the tool that best supports your workflow. For me, one of the most important IDE features is OSGi tooling. I spend my days writing bundles, crafting configurations, wiring together services and deploying OSGi based applications. Nothing compares to the OSGi tooling provided by Eclipse. The OSGi tooling is part of the Plug-in Development Environment. The reason it’s not called the OSGi Development Environment is strictly historical (these guys were doing OSGi tooling before it was cool).

Feature based targets and launch configurations make configuring your OSGi applications much more manageable. Features provide developers a way to ‘group’ bundles together and talk about things at a higher level. Instead of talking about the p2 engine, and p2 director, and p2 core, and all other bundles that ‘make-up’ p2, we can group these together into a feature — the p2 feature. For those of you wish you craft OSGi applications that include p2, you can simply use the p2 feature (instead of worrying about the particular bundles that constitute this feature). The real thank-you for this feature goes out to Ankur Sharma and Curtis Windatt.

This will become more and more important as Eclipse continues to grow in the Run-time space.

Tags: helios

Tags: iAd, IPad, iphone, protocol, rap

Pop quiz: Can you name any ‘high quality‘ software that has been consistently delivered on-time, for 8 years in a row?

Yes folks it’s that time of year again! It’s time for the Eclipse Release Train to start revving up its engine for another high quality release. Unlike other software — which gets delayed, bumped or put-on-the-back-burner — Eclipse just simply, delivers.

The official Eclipse release — named Helios — is not arriving until June 23rd, but in keeping with tradition, I thought I would help count down the next 10 business days with the Top 10 Helios features I’m most excited about.

As many of you know, Eclipse is no longer Just a Java IDE. Eclipse is a tooling platform, Eclipse is runtime stack, Eclipse is set of world class IDEs, Eclipse is an eco-system, Eclipse is like family. Before I start to count down my favourite features, I should state that I only use a small subset of Eclipse. There are some really exciting things happening in the C/C++ development tools. The SWT team has added some fantastic new MacOS and Windows Vista support.

The Birt and Web tools team continually pump out great code. While all these projects are doing cool things, sadly, I don’t get to use them on a day-to-day basis.  Because of this I can’t talk about them here. As I’ve said in the past, this really is My Top 10 List. So please — if you disagree with me — write your own Helios Review (you might even win a prize).

Number 10 on my list is Resource Improvements. This includes everything from virtual folders to the file permission management.

As well, a number of enhancements have been added to the Open Resource dialog.

Thanks goes out to the Resource Team, and in particular Serge Beauchamp, for this.

In addition to the improvements to resources, one of the oldest feature requests related to files has finally been fixed: Bug 4922 (yes, a 4 digit bug number). Eclipse now has the ability to open a file from the command line (and have it open in an existing running instance of Eclipse). While this may seem like a trivial enhancement request that all IDEs should support, the API behind this feature is what makes it so interesting. As RCP developers, you can make use of this API to load data files into other running processes. As Eclipse programmers you can double click Java files and have them open in Eclipse.  And like everything in Eclipse, this works across platforms.  If you’re interested in the technical details, checkout Andrew’s Blog. Huge kudos go out to Andrew Niefer, Kevin Barnes, and Oleg Besedin.

Tags: helios

It’s been overcast and raining here in Victoria B.C. (Canada) over the past 2 weeks. It’s a long way from the dog days of summer, but a good time to focus on docs.  In fact, the Eclipse team has been focusing on documentation during this final release candidate.  In particular, the p2 team is putting some docs together on our new API (Yes, p2 has “real” API now).

Last year Andrew Niefer gave me a few tips on self-hosting the doc / help contents and I thought I would share these.

The help contents are written in HTML files and live in OSGi bundles (like everything else).  For example, the platform doc lives in org.eclipse.platform.doc.isv. Once you have your bundle loaded (from CVS, git, wherever) you can edit the contents like any HTML other document.  When you want to see how the contents will appear to the user, simple launch the org.eclipse.help.base.infocenterApplication, and specify a port as a VM argument (-Dserver_port=4419 for example).

Once running, you can now browse the help contents using your favorite browser (and even change the contents on the fly).

Of course if we get our butts in gear and follow David Green’s advice, we won’t need to edit our docs this way.

Tags: documentation, helios, p2

Based on your feedback on my last blog posts, I’ve implemented a first prototype of the RAP protocol. Here’s an update on the current state. Several functions are now implemented e.g. server side message creation, client side message processing, client side message creation and server side message processing. The cool thing about all this stuff is that it works already with the RAP lifecycle. To demonstrate the use of the protocol, I migrated the Shell widget. You can see the results in the screenshots below.

The first screenshot shows the protocol based shell. You can see that FireBug is open and is showing the JSON response from the server. The second screenshot shows a JSON request that was sent from the client to the server. The current protocol implementation is a hybrid, which means that it uses JavaScript and protocol messages. With this hybrid it’s possible to run the RAP workbench on top of the protocol based shell.

If you want to test this shell yourself you can use the RAP protocol git mirror which can be found on github. At the github wiki you can see what bundles you’ll need to run the protocol based shell. To start the protocol shell just run the launch configuration within the org.eclipse.rap.rwt.protocol.playground bundle. The code for the protocol is in a very early state, so please be warned that there could still be drastic changes in the code base.

The next step in the development of the protocol will be to test it on a different client technology. For this purpose a demo for the iPad would be the perfect candidate. AdLib is a JavaScript library which brings native like widgets to the iPad’s mobile safari browser. And, I think it will be possible to use this library with RAP and the protocol. I will keep you posted on the progress of the iPad demo. Looking forward to your feedback.

Tags: eclipseRT, protocol, rap