Yesterday I stumbled upon a pretty interesting google code project, the Google Visualization API.  The Google Visualization API enables you to expose your own data through a number of Visualization Widgets, which are made available as a service.

Here is a screenshot from the geo map widget:

Google Graph Widget

This got me thinking: Is there place for “service widgets” in the Eclipse platform (possibly in e4)? These could likely be used with RAP fairly easily, but we could also wrap these up with the browser widget and expose a Java API similar to SWT/JFace (or even an EMF model to represent the data) for rich client applications. Of course, for these to work your users would have to be connected to “the cloud”.

Thoughts?

Tags: e4, eclipse, google

FYI Eclipse committers, the Galileo IP deadline is TOMORROW.

If you have any third party libraries or contributions that need to be reviewed, get them in now!

Tags: eclipse, galileo

I have been pondering exceptions quite a lot lately. Especially how to break the bad news to the user. From a user’s point of view there are three categories of errors:

1. User or domain errors

These errors occur when the user enters invalid data, or tries to perform an action that the domain model does not allow. Typical examples of this kind of error are things like trying to enter a duplicate key or trying to delete an item that is still being referenced. Note that these kinds of errors are usually not even worth logging. These types of errors can usually be recovered by the user himself, either by choosing an alternative action, or by manipulating the model in such a way that the action becomes valid. While the exception usually describes what went wrong, the error message displayed to the user should also explain what can be done to correct the situation in such a way that the desired. Ideally the error dialog should also allow the user to directly apply those fixes in order to achieve his original goal. Prime example of such an implementation: Eclipse quick-fixes. While telling you what you did wrong, they also offer to repair your mistakes. In fact they are so convenient and helpful that I have come to rely on them when writing code: Write pseudo-code, then let quick-fix sort out the details.

2. Infrastructure errors

These kinds of errors are usually intermittent failures of one of the subsystems the application is running on. Usually these are network outages, a full disk or a server on fire. Here a detailed error message is helpful to enable the user to track down and rectify the problem. Depending on the type of application and business environment, it might also be a good idea to notify the responsible systems administrator that a problem has developed, so he can get a little head start before the hordes of users demand to know why they can’t access their TPS reports. In rare cases there might be backups or fail-overs in place which can be used in case of such infrastructure problems.

3. Programmer errors

While we all strive to avoid it, there are going to be programmer errors (internal errors aka bugs). These are basically all errors not in one of the above categories. The most common manifestation of these types of errors is the dreaded NullPointerExceptions. But we’ve all seen the code comments declaring: “This should never happen.” Sometimes assertions and assumptions we make when writing software turn out to be wrong. The best we can do in these situations is to fix the problems as soon as possible. Ideally the application in questions gathers as much information surrounding the error as possible, then allows the user to report this information, in addition to his notes about what he was doing at the time of the failure. The message to the user should be along the lines, “We are sorry for causing you trouble. Let’s make sure this particular problem does not show up in the future.” The idea is to show users that their feedback is not a pointless exercise, but an effective way to make their daily lives a little better by improving their tools.

Exception classes

The problem with many exception hierarchies in libraries and applications alike is that they distinguish exception classes at component, interface or service boundaries. If the StockTickerService returns a CannotReadStockSymbolDataException, the caller has oftentimes no way to distinguish between user error (Stock symbol does not exist), infrastructure error (server unreachable) or internal error (could not handle values above 255). This makes handling these exception at the user interface level quite challenging. Sure you can take the easy way out and display the message to the user, maybe log it and be done with it, but the application itself has no way to distinguish between the different levels of severity. A typo in the input field is nothing to write home about, while not being able to handle values above 255 is a systematic failure that might render the system unusable.

My point here is this: Being able distinguish the type of exception is often helpful when trying to recover from an error. But in my experience errors are not seldom recoverable. And in these cases it is more important to know who to inform about the failure. This makes the triage of errors much simpler, administrators and developers get notified about problems in their areas of responsibility, but are not flooded with reports about “trivial” user typos that drown out the real issues.

Tags: error, exception

I’m so filled with joy that we’re going to have an OSGi Tooling BOF at EclipseCon this year. Here’s what we have for the abstract so far:

OSGi development tooling is the next big challenge for the adoption of OSGi in the enterprise. There are a number of great tools out there: PDE, BND, Maven, Sigil etc but little coherency between them. The OSGi Alliance has arranged a Tools Summit after EclipseCon and this BOF is a chance for people to come and raise any comments, criticisms and suggestions around OSGi development tooling prior to this summit.

The BOF is being organized by David Savage, Peter Kriens and I. For those who don’t know, there’s quite a bit of fragmentation in the OSGi tooling space. PDE has been tooling OSGi forever but has some baggage and an Equinox specific focus that some peole don’t like. More importantly, it’s not as extensible as I would like it to be. There are also some other newcomers that are starting to explore the OSGi tooling space. They take some different approaches but I think we can all work together.

I have a dream that we would all build on the same OSGi tooling stack… reuse technologies where they make sense (e.g., why isn’t PDE using BND for manifest generation?), there’s no excuse to reinvent the wheel. We all want to see OSGi succeed.

If you have any comments on what should be discussed at the BOF, please comment on the submission.

Tags: eclipse, OSGi, pde

I’m fascinated with Twitter on so many levels.

First, that the idea is so simple… they practically created some weird hybrid of IRC and YTalk for the web. Second, I have no idea what their business model is. Third, I find it amusing that I can complain about my delivered groceries (I don’t like supermarkets) and have someone respond from the company in a few minutes… creepy and cool.

Regardless of what I say, it seems the uptake of Twitter in the tech community is huge. One way I use Twitter is to follow what’s going on in the Eclipse/OSGi communities. For example, I use the TweetDeck client and have some queries based on tweets containing specific words:

If you’re interested in following people on Twitter around the Eclipse/OSGi community, here are my recommendations:

Neil Bartlett
Chris Aniszczyk
Ian Skerrett
Markus Kohler
EclipseSource
PlanetEclipse
Martin Lippert
Mik Kersten
Boris Bokowski

I also created a page on the Eclipse wiki if people want to add themselves there.

Happy twittering!

Tags: eclipse, OSGi, twitter

Jetty is moving to Eclipse! Someone asked me what I thought about this.  Well, as the Eclipse Runtime PMC co-lead how could I not be thrilled with this direction? This is a bold move by a very competent and exciting team with great technology. It is awesome for the runtime movement at Eclipse and really completes the lower level picture of our componentized server  side story.

Before I go too far, let’s nip any rumours in the bud.  Jetty is not moving to be OSGi based. That might be “a good thing”™ but Jetty appears to be meeting its goals with the current architecture. They are however taking OSGi integration seriously.

Several years ago we used Tomcat inside the Eclipse SDK for providing help content.  This worked but was big and a clumsy. Then someone, might have been Simon Kaegi, had the bright idea of using Jetty.  Same difference right? That’s what I thought.  I was wrong.

The most important characteristic is that Jetty is designed to be highly embeddable.  It is not the container to end all containers but rather an element of the solution. This fit really well into both the Eclipse mentality and our particular usecase. Jetty is small, light-weight and performant. You can spin up a Jetty instance whenever you want.

With Jetty at Eclipse we get several things.

Even without moving to OSGi there is room for improved integration. The various HTTP and server related OSGi-specs have been around for a while and could use some updating. The Jetty team with their involvement in the Servlet 3.0 spec and deep experience are well positioned to, say, provide an OSGi HTTP Service implementation that exposes more modern servlet function.

Deeper integration with Equinox and perhaps even lighter-weight configurations for particular Eclipse needs may also be possible.

Little known is that the Jetty folks also do client transports. There is potential there for some even better install performance for p2 and other web intensive aspects of Eclipse.

I for one am looking forward to working with the Jetty folks on all of these.

The story is not onesided IMHO.  For Jetty this is a really smart move.  Being part of the Eclipse ecosystem positions Jetty in a whole new realm of consumers. The rigor of the Eclipse IP and release policies will no doubt add to the already stable view of Jetty. The increased attention likely to be paid to it by the Eclipse ecosystem, sharing in the buzz around the Eclipse brand, release trains, conferences and overall adoption of Eclipse can only be good.

In short, welcome to the fold…

Boris Bokowski and I are in charge of the UI and RCP track at EclipseCon 2009. It took forever to weed through all the submissions, but we eventually made some choices and I think we put together an excellent program. We have three tutorials:

Building Commercial-Quality Eclipse Plugins
RCP Mail 2.0: Commands, Common Navigator, and Data Binding
Advanced Eclipse Rich Client Platform

These tutorials should provide great coverage for beginners and even experts. For beginners, I’d highly recommend Dan Rubel and Eric Clayberg’s tutorial on building commercial quality plug-ins. These are the same guys behind the book that shares the same name as the tutorial. For experts, the other two tutorials are good options, however, I’m personally excited about the RCP Mail 2.0 tutorial as I want the outcome of that tutorial to result in a new PDE template that can be used by all. At least, that’s my hidden agenda in vouching for that tutorial

For long talks, we have plenty but here are three of my favorites:

Eclipse on Rails and Rockets
Sleeping Around: Writing tools that work in Eclipse, Visual Studio, Ruby, and the Web
Max and John’s Excellent Plug-in Adventure: The Highlight Reel

The main stage talk should be really interesting as you get to hear from two adopters of Eclipse… and how they used Eclipse technology within NASA and the Swiss Railway system. Then you have a talk by some old Eclipse committers that decided to stress themselves out by writing tools that run anywhere… from Eclipse to Visual Studio. Finally, there will be an entertaining talk from Max and John about Eclipse plug-in development anti-patterns.

We also have a lot of short talks but here are three I’m personally looking forward too:

Carbon Dating: The treacherous path from Carbon to Cocoa for SWT
Nuclear Eclipse : Eclipse in nuclear power plants
Real World RCP

It’s always entertaining to hear Steve Northover talk, he’s like a wise guitar-playing sage. Joining Steve will be Scott Kovatch from Adobe, they will talk about the challenges in getting the SWT Cocoa port ready for Galileo. I’m impressed with the work so far as I’ve been using the SWT Cocoa port since Eclipse 3.5M4 and it’s been pretty stable. It will definitely be ready for the prime time when Galileo ships. The other two short talks I like are more case study related… and always fun to listen to. I mean, Eclipse in nuclear power plants… that’s awesome!

So there you have it. All I can say is that I hope you enjoy the program this year! See you in March!

Tags: eclipse, eclipsecon, nasa, rcp

Have you ever worked with OSGi Declarative Services (DS) within an Eclipse context… like an RCP application? Do you remember the pain of figuring out how to hack DS so it’s always started so your services can be available? Well, in Eclipse 3.5, this process will be a lot easier. For example, starting with Eclipse 3.5M5, PDE will allow you to modify start levels of PDE-based launch configurations:

PDE is also smart enough to suggest that DS should always be started so you don’t always have to worry about it. On top of that, the product definition format now has the ability to modify start levels which should help you when you’re building and packaging RCP applications:

If you don’t know much about DS, but would like to learn, I highly recommend these two introductory articles by Neil Bartlett:

• Getting Started with OSGi: Introducing Declarative Services
• Getting Started with OSGi: Declarative Services and Dependencies

The Equinox OSGi book also has great, indepth content on Declarative Services if you’re interested.

In the end, I think DS is a great lightweight way to work with services as it helps you avoid a lot of the tricky and error-pone code you have to write while working with services. Hope this helps!

Tags: eclipse, equinox, OSGi, pde, tips

To JAR a bundle or not to JAR, that is the question…

When you’re packaging bundles for deployment, 99.9% of the time you will want to have the bundle packaged into a single JAR. There are many reasons you would want to do this, whether it’s space savings or a way to combat that evil Windows path limitation. In Eclipse land, the way a bundle is packaged in a build was typically controlled at the feature level. In an Eclipse feature, you could declare a bundle and specify whether the bundle is needed to be unpacked or not (via the unpack attribute). If you had an Eclipse-based product that was simply bundle based, PDE Build had to make guesses on whether or not to pack the bundle or not. This was done using a simple algorithm, if the Bundle-ClassPath header is present in your manifest and the classpath contains a ‘.’ (or is not defined, since ‘.’ is the default), then you will end up with a jar. This guessing can problematic for developers when you don’t want pack a bundle because of technical reasons.

So what’s the solution?

I have good news, in Eclipse 3.5 (starting with the 3.5M5 milestone), PDE supports the new Eclipse-BundleShape header. This header simply has two values, “dir” or “jar,” which specify how the bundle should be packaged. This header is also used by p2 so when you go to publish your bundle in a repository, the metadata is properly generated.

In the end, we now have a solution that allows for a finer granularity in which a bundle’s packaging information can be specified.

I hope you find this information helpful!

Tags: eclipse, OSGi, pde

I’m excited to learn that certain computer science students will be contributing to Eclipse (WTP in particular) as part of university class credit. Personally, I think this is fantastic and much better than say killing yourself over automata theory

As a student, I think one of the best ways to prepare yourself for a career in software is contributing to an open source community project. Depending on the project, you can learn about various development methodologies, source control systems and even project politics! From my own experience, I learned a lot when I spent time committing to the Gentoo project back in the day. I learned the importance of community building, breaking builds and how to work in a highly distributed team. Oh those were the days…

If you’re a student and interested in working with the Eclipse community… Eclipse is participating in the Google Summer of Code program this year again. Feel free to post your project ideas!

Tags: eclipse