Well… mostly.

The code for the Eclipse Business Expense Reporting Tool (you may have noticed that I’ve changed what the ‘T’ stands for) has been checked into CVS per the approval of CQ 2310 and subject to the constraints of the parallel IP process.

I don’t consider this a complete example yet. The initial code contribution is only a starting point, and—while I think we’ve made a good start on implementing the values of the Examples project—there’s still a lot of work to do. To start with, there is an embarrassing lack of unit tests. I have added quite a lot of (hopefully valuable) comments, but more are needed. Additional documentation of the architecture is required, along with discussion of some design points, and links to other sources of useful related information. I also have some ideas for simplifying the bits that permit platform-specific (RCP, RAP, and eRCP) customization of the views.

I spent some time yesterday cobbling together a website for the example. The website has instructions (along with handy Team Project Sets) for obtaining the code and rudimentary instructions for setting up your environment to make sense of it all. I have started the process of creating the Bugzilla component for EBERT (Webmaster Matt assures me that the new inbox for the component will be online tomorrow). In the meantime, if you just can’t wait, feel free to create bugs against the “General” component and I’ll move them after the “Expenses” component has been created.

I’ve also requested that the old eclipse.technology.eep newsgroup be retired and replaced by a shiny new eclipse.technology.examples. The mailing list will remain examples-dev@eclipse.org (like most other Eclipse projects, the mailing list is intended for discussion amongst project committers).

Good times lie ahead.

Radoslav has taken it upon himself to get EBERT running on Sprint Titan (based on eRCP). How cool is that? Let me answer that for you: very cool.

See some screenshots here. I’m looking forward to Radoslav’s contributions to the project.

I blogged last week about an example application that I’ve been building. Building good examples is pretty hard: you want an example to be simple enough to understand. At the same time, it has to be real enough to useful and expose real issues. I think that this application strikes a reasonable balance. The Eclipse Business Expense Reporting and Tracking (EBERT) application is a relatively small, but provides a valuable service. At least as a business traveler who has to work with Excel-based expense forms, it’s valuable to me.

Here’s a snapshot of the RCP version of EBERT:

Here’s what it looks like in RAP:

Note that the RAP version is running in a browser embedded in an Eclipse editor. It also runs fine in a regular browser like Firefox.

Here’s what it looks like in eRCP running on a Nokia E90:

You’ll notice some similarities and some differences. The really cool part is that some 90% of the code (estimate) is exactly the same across platforms. That 90%—the exact same code without recompiling, repackaging, or manipulation of any sort—is deployed on the desktop, the server, and a phone. This is one of the great things about Equinox and the various runtime platforms at Eclipse: the exact same component model, Equinox, is used everywhere.

Here’s a high-level architecture of what’s going on:

The common bundles—those in the middle—contain most of the interesting behaviour. Specifically, these two bundles contain the basic business models (core), and the various views and custom widgets (ui). Underneath these common components are the various runtime platforms which all themselves sit on Equinox (actually, the E90 uses Prosyst’s implementation of OSGi).

At the top are the various “application” bundles. Each of these bundles pulls the pieces together for one of the platforms. The “application” bundles provide some customization of the views, and—in the case of the eRCP version—some navigation glue that manages the views in the absence of perspectives (which are not supported on eRCP due to screen space limitations).

Yesterday, I (finally) submitted it to the Eclipse IP review process as the initial contribution for the Eclipse Examples project (CQ 2310). There’s still a lot of work to do (the application doesn’t quite live up to the Examples project’s values yet), but we should hopefully soon have some code where you can find it, look at it, and maybe contribute.

I’ve been spending a great deal of time working with Eclipse runtime technology recently. Specifically, I’ve been building an example application that deploys using Eclipse Rich Client Platform (RCP), Rich Ajax Platform (RAP), and embedded Rich Client Platform (eRCP). The application itself is simple enough: I like examples to be as simple as possible, but useful, so I built an expense tracker. I figure that, if I can make it useful enough for my purposes (i.e. help me keep track of my travel expenses and automatically fill out those forms I hate love so much), it will give me great motivation to keep it up-to-date and new versions of the technology becomes available.

I started first with an RCP version of the application. I’ve been building applications using RCP for a while, so this seemed like a natural enough step.

After I got some bits of the functionality working, I switched over to RAP. The switch to the technology itself was pretty straightforward. I installed the development plug-ins from the update site (they provide some handy launchers that make testing super easy), and downloaded and unpacked the runtime target platform. RAP applications, just like RCP applications require a target platform which provides a set of bundles that form the foundation of the application. The cool thing about RAP is that it lets you build applications using almost exactly the same set of APIs that you use when building RCP applications. In the ideal case, you switch from an RCP target to an RAP target and you’re in business.

While RAP provides a growing subset of the the same APIs made available to RCP developers, they are packaged differently. In my original work, I had specified a number of bundle dependencies. Since the names and organization of the bundles in RAP are, in some cases, different than those of RCP, many of the dependencies could not be found (package and class names are the same). I switched from using bundle dependencies (Require-Bundle) to using package imports (Import-Package). I’m not sure if there is a recommended practice in this domain yet, but I opted to use package imports for all “system” dependencies, and bundle references for dependencies on other bundles I created.

The conversion of the application from RCP to RAP was pretty quick and relatively painless. With this success in hand, I turned my attention to eRCP.

The conversion to eRCP required a bit more work. First, I had made the cardinal sin of using Java 5 (language syntax and libraries). Most of the migration effort to eRCP was a pretty mechanical process of converting to the version of Java supported on the device. Specifically, I had to convert everything down to Java 1.3 and CDC-1.1/Foundation-1.1 libraries. This required more than just changing syntax as I had used some APIs not included in the target environment; this sent me searching for replacements for functionality such as regular expression parsing. Once I worked out my addictions to Java 5, I turned my attention to the user experience. Before I started down this path, I knew that eRCP didn’t have a notion of perspectives (tiny screens don’t lend themselves to perspectives), I tried to carefully design the various views in my application to work with this restriction.

My initial effort has resulted in an application that runs on all three platforms. Some 90% of the code is exactly the same on all platforms. In fact, I have a handful (recall that I wanted to have a relatively small application) of bundles that are just shared and so are immediately testable and deployable on the various platforms.

I have an “application” bundle for each platform that pulls all the parts together in different ways. The RAP version of the application presents itself in full screen (full browser?); the RCP version uses the Nebula CDateTime widget, the eRCP version adds explicit navigation between views and leverages the special “command” buttons available on a device. I can envision other “application” bundles that assemble and manage the components for different types of devices; the way that I interact on an iPhone (at least theoretically) is different than I do on the Nokia E90 I’ve been playing with; I can capture the different navigation aspects in a separate bundle while still leveraging the 90% functionality reuse.

I intend to talk more about this application over the next few days and weeks (and post some pictures). When I get home from from JavaOne this week, I’ll start the process of contributing this application to the new Eclipse Examples Project. In the meantime, I’ll be at the Eclipse booth at JavaOne. Find me there (or at the Thirsty Bear on Wednesday night).

The Eclipse Examples project has been provisioned! I’ll spend some time later this week setting up the landing page and get to work moving some of my examples into the new project. Frankly, it’s exciting as heck for me.

Over the last few days, I’ve been dreaming a bit about some of the code that I’d like to move into the project. I have a few applications based on Eclipse Rich Client Platform (RCP) that I’ve built over the last couple of years for personal use (or at least not for official Eclipse Foundation work). As I was going through the code for one of the applications, it occurred to me that the most interesting bits of the application really had nothing to do with any specific Eclipse technology…

But that’s the point, isn’t it?

I remember a project I worked on 15 years ago or so. I spent quite a lot of time building infrastructure to make the “interesting bits” of the application work. I probably spent a few hours making a relatively generic selection service. I recall spending weeks developing generic graphical components that supported grouping, drag and drop, etc. I also spent weeks building an object/relational persistence mapping framework. One of my colleagues spent months building one of those “notebook” widgets (tabbed panel) with a stylized spiral binding that were all the rage into those heady OS/2 days.

Ultimately, the customer didn’t care at all about the ability of the application to make selections, drag and drop little boxes, or click on tabs to expose pages of information; they cared that their business analysts could be productive with the application. All those generic plumbing pieces were merely the cost of doing business. I needed to have those things as a foundation for the real application behaviour. I needed to have those things, but they weren’t of any specific value to the customer. What was valuable to the customer was the application we built on top of those generic frameworks. This is where we found the really interesting code: the accounting algorithms, the business rules, the business logic, etc.

I love the opportunity that project gave me to learn how to do all that funky stuff, and it was on this project that I learned about project management (via counter-example, but that’s a story for later). If I had do this project over, it’d be a really good fit for Eclipse RCP, the Eclipse Graphical Editing Framework (GEF), EclipseLink, and the Eclipse Modeling Framework (EMF). We’d be able to complete it in probably a quarter of the time with far more functionality. To boot, we’d be able to deploy it over the web using RAP (how cool is that?)

A lot of organizations have already picked up on this. You can read some of their stories on the case studies page.

I’ve been speaking with students, professors, and researchers at several universities. They see Eclipse as a bit of a competitive advantage: you see, a lot of the other universities haven’t caught onto the fact that—by using Eclipse technology as a foundation for your research work—you can maximize the amount of time you spend working on solutions to your actual problem and minimize the time you spend working on the infrastructure necessary to make everything work. Eclipse supplies the “make everything work” part, you solve the problem that needs to be solved. Sounds like a productive relationship.

I’ve been trying to decide how to work with Equinox services in the user interface.

I’ve started modifying the Organizer application that will soon be part of the Eclipse Examples Project (once it’s provisioned) to use Equinox services. I’ve got a view that updates its appearance based on available services. The implementation is straightforward enough. The view has a ServiceTracker that watches as services of a particular type are added (or removed). As these services come online, the tracker notifies me of the change and I add a button corresponding to the new service to the view. The button is configured (text and image) with information from the service; when clicked, the button invokes behaviour on the service. When the tracker notifies me of that the service has been removed, I dispose() the button (thereby removing it).

It’s pretty cool to see the user interface change in response to commands typed in the Equinox console. Stop the service and the button disappears, start the service and the button reappears. Lather, rinse, repeat. Hours of fun for the whole family.

One advantage of this technique is that I can control aspects of my user interface by selectively enabling services. I can imagine a scenario where, using declarative services, a collection of services depend on the existence of a “role” service. For example, administrative behaviour might be defined in a collection of services that depend on the existence of an “Administrator” service that is only created if the user’s permissions include administrative operations. With declarative services, it’s easy to specify a cardinality on your dependencies; a service can specify, for example, that exactly one service of a particular type must be started before it will start. This isn’t exactly what I have in mind with the example I’m working on, but might be an interesting proof of concept.

The example code is still a little rough. I’m smoothing it out in anticipation of the Examples project being provisioned. In the meantime, I may try to develop a simpler example and post some of the code.

This morning, after the throught-provoking keynote by Cory Doctorow, I sat in on the Eclipse Riena Project session, presented by Christian Campo (compeople AG, Frankfurt/Main, Germany)

Fundamentally, Riena is about distributing services across tiers. It’s born from a need to have applications that are lighter than rich clients, but more functional and performant than light clients. Applications built on Equinox (like those leveraging Eclipse Rich Client Platform, or OSGi-based server-side applications) are compositions of bundles and services. Equinox services are conceptually similar to web services; they are created, registered, discovered, invoked, deregistered, updated, etc.

One big difference between web services and Equinox services, is that Equinox services tend to be used locally (i.e. within a single JVM). Riena extends this to allow bundles and services to be distributed across tiers by providing a mechanism for creating proxies for OSGi services on the client. Proxies exchange messages and data to server. The true location of the service is transparent to the code that makes use of the services; you talk to the service like it’s local and it takes care of communicating with the real service wherever it lives. Riena includes infrastructure that automatically creates a proxy and connects it to the running service on a remote machine. I assume that it uses the Proxy class in Java to automatically create an instance of the specified interface that knows how to talk to the remote service.

Riena provides some other handy services, like authentication and authorization. The current implementation uses JAAS security for now., but they intend to migrate to Equinox security (which is currently part of the Equinox Incubator) in the future. Authentication is provided via a service that runs on the server, and is exposed to the client (via proxy). Once established, credentials flow from the client to the server automagically as part of the communication. Some infrastructure is provided to manage authorization.

Riena has a “Visual Vision”. Christian showed a user interface that they created for a client. The user interface, coded using Swing (the work began several years ago before they were fully introduced to the wonders of Eclipse Rich Client Platform), shows some interesting user interface concepts. Christian made a good point that, while the flexibility in the “Eclipsey” user interface makes sense to us, end users are often thrown off by it (e.g. how do you get a view back when you close it?). Development of the user interface concepts hasn’t been started in earnest yet, but is on their plan.

I hear a lot of good stuff about Eclipse Rich Client Platform (RCP). I also hear some criticism. Perhaps the most popular criticisms that I’ve heard has to do with the scope of RCP. Some members of the community have the opinion that RCP doesn’t go far enough. It’s concerned, they say, exclusively with issues of user interface. They say that higher-level support for things like persistence, communication, domain-specific models, and so on are necessary. Some even suggest that RAD tools would be nice. Strictly speaking, it isn’t true that RCP is exclusively concerned with user interface issues since RCP also provides a kick-butt component model thanks to the Equinox project, extreme extensibility, built-in update support, and so on (but who am I to argue with these rather abstract members of the community?)

I agree. All that would be nice. The funny thing is that we do already have much of the desired functionality. But what do we do about it? I’d love to learn your opinion on the topic.

In that spirit, we’re running the RCP Experience Workshop at Eclipse Summit Europe (ESE). If you’ve got experience building RCP applications, we’d love to have you there. If you’re thinking of starting with RCP, we’d also love to have you there. Heck, if you’re just remotely interested in RCP, I’d still love to meet you (even if you can’t make it to the workshop).

I have some simple goals for the workshop. I’d like to know what we can do to make the RCP experience better for everybody. I’d like to discuss how we might go about driving change (we can’t expect the Eclipse project to do all the work).

Qi Liang has authored an excellent article titled “Using the BIRT Chart Engine in Your Plug-in” that discusses how you can incorporate BIRT charts into your own applications. This article introduces the basic concepts of BIRT Chart Engine, explains what BIRT Chart Engine is composed of, and illustrates how to create a chart and use it as widget.

A few days ago, I added a link on the Eclipse Resources to a new article on Eclipse RCP written in Arabic (the title translates into something like “The establishment of professional programs through Java / RCP”) by Bashir Storm. I have to say that I think the article looks really cool, despite the fact that I can’t understand a word of it without help from Google Language Tools. The beta support for Arabic to English translation does what I think is a pretty good job.

Frankly, I think that it’s very cool that folks like Bashir and Qi are doing great stuff with Eclipse in far off lands that I dream one day of visiting…

If you’ve found the “Colors and Fonts” page in the Eclipse Workspace Preferences, then you already know that you can customize Eclipse to look as awful as you’d like. Or maybe you went different route and changed the colors and fonts to better suit your personal tastes.

Many aspects of the workbench can be tuned. When you change a value, it’s stuffed into a preferences store and kept on your disc so that those preferences come back the next time you start. More specifically, those preferences are stored in files found in the [workspace]‌/.metadata‌/.plugins‌/org.eclipse.core.runtime‌/.settings directory.

You can override the default preferences in your Eclipse product (or RCP application) without making the user play around in the preferences dialog. This is done by providing preferences overrides. You do this by adding a property to your product declaration in the plugin.xml file like this:

<extension id="product" point="org.eclipse.core.runtime.products">
    <product application="PlayingWithPrefs.application" name="RCP Product">
        <property name=”preferenceCustomization” value=”preferences.ini”/>
    </product>
</extension>

With this addition in place, the preferences.ini file—located in the plug-in’s root—is defined. Here’s an example:

# Use curvy tabs
org.eclipse.ui/SHOW_TRADITIONAL_STYLE_TABS=false

# Tabs display in a large italicized font.
org.eclipse.ui.workbench/org.eclipse.ui.workbench.TAB_TEXT_FONT=1|Tahoma|15.75|2|WINDOWS|1|-21|0|0|0|400|1|0|0|0|3|2|1|34|Tahoma;

# The active tab displays as red to green gradient with blue text (yuck)
org.eclipse.ui.workbench/org.eclipse.ui.workbench.ACTIVE_TAB_BG_END=255,0,0
org.eclipse.ui.workbench/org.eclipse.ui.workbench.ACTIVE_TAB_BG_START=0,255,0
org.eclipse.ui.workbench/org.eclipse.ui.workbench.ACTIVE_TAB_TEXT_COLOR=0,0,255

# The inactive tab displays as blue to green gradient with red text (yuckers)
org.eclipse.ui.workbench/org.eclipse.ui.workbench.INACTIVE_TAB_BG_END=0,0,255
org.eclipse.ui.workbench/org.eclipse.ui.workbench.INACTIVE_TAB_BG_START=0,255,0
org.eclipse.ui.workbench/org.eclipse.ui.workbench.INACTIVE_TAB_TEXT_COLOR=255,0,0

And here’s what the RCP Mail sample application looks like with these customizations applied:

You can set more than just look and feel preferences as well. You can override any value that’s stored in preferences. If you look through the .settings directory, you can get a sense for the kinds of preferences you can override in your Eclipse product.