Whenever I think of p2, I just can’t shake the image of the little dog in the stories we used to make up in French class in elementary school. “Pauvre Pitou. Il a sauté par la fenêtre…” But I digress…

Today I did a little experiment with p2. I downloaded one of the Ganymede M7 packages and installed in into a shared location on my file system. This particular system has Fedora 8 Linux installed, so I opted to put Eclipse in the “/opt” directory. Anybody can read from this directory, but only root can write.

I then launched Eclipse as a non-root user and opened the “Software Updates and Add-ons” dialog and added a bunch of stuff from the Ganymede update site. From a user’s perspective, everything just worked. p2 uses some smarts to pick the best mirror from those available, and downloads all the required bits and pieces using multiple threads. Overall, the experience was pretty seamless.

Under the covers, there was more going on. Of course, running as non-root, p2 couldn’t write the downloaded files into my /opt/eclipse/... directory, so it created a hidden directory in my user home, /home/wayne/.eclipse with all the new stuff. It also stores my configuration there.

This is good stuff. If I really was sharing this workstation with others, I’d want to share the bulk of the common plug-ins, but have the ability to customize my own experience by adding my own additional plug-ins without having the custom experience of other users imposed on me. I understand that the p2 framework provides support for updating the shared installation, but this isn’t exposed in the user interface yet. In fact, it probably doesn’t make sense for it to be exposed in the workbench, a separate (perhaps headless) application might be more appropriate for that anyway.

I don’t know if the p2 developers thought of everything, but they sure thought of a lot of things.

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.

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.

This video podcast shows a simplified example of Equinox services in action. It shows declarative services being dynamically discovered using a service tracker that updates the user interface to show the services that are available. The example also shows Equinox declarative services, and the JFace databinding APIs in use.

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.

Sometimes it feels like I’m stalking Frank Gerhardt. Or maybe I just like listening to German speakers. Whatever the case, it seems that almost every single talk I’ve attended has been presented by Frank, or one of his countrypersons…

This afternoon, I’m attending “Server-Side Eclipse - the dynamic server platform based on OSGi” presented by Jochen Hiller (Deutsche Telekom AG, Germany), Frank Gerhardt (Gerhardt Informatics).

“Server-side Eclipse” is a term that shocks some people. What does it mean for Eclipse to run on a server? If perception is reality, then perception tells us that “Server-side Eclipse” means “Eclipse IDE for Java Developers running on the server”. What we really mean is “Equinox running on the server”. Equinox is the component model, based on the OSGi specification, that underlies Eclipse. An Eclipse product (like Eclipse IDE for Java Developers) is a collection of plug-ins (or bundles) and Equinox is what makes sense of it all and makes it work. Equinox can help you make a server-side application based on bundles; Equinox makes sense of it all.

One of the big deals in Equinox is services. Bundles can register services with the service registry. The notion of a service is very similar to that of a web service, but with much less weight. Services are registered and unregistered, they can be discovered, and behaviour invoked. One of the tricky things about services is that they can easily come and go. By their nature, bundles are very dynamic and can be started, stopped, unloaded, updated, etc. at any time. As bundles come and go, so do their services. ServiceTrackers help us keep track of the comings and goings of services; we can use a ServiceTracker to get a handle on a service, but we need to be careful not to depend on that handle being valid forever. As a general rule, you get the service, use it, and then unget it. The next time you obtain the service, it might be an entirely different implementation. Or it might not even be there. You need to be ready for that.

The demo they’re running is similar to a tutorial/demo that I built a couple of weeks ago. Their demo differs in that they’re showing a lot more of the general coolness of dynamically installing, starting, and stopping bundles. Their demo also takes it one step further than mine by showing an Über-cool RESTful web service (an Equinox service implementation of a RESTful web service).

In what I am certain is an attempt to make my demonstration seem pitiful and weak, they’ve shown how a new version of a bundle can be installed and started alongside the old version, which is then stopped. All this, while a client is constantly pinging the server and showing us how the output changes as the new bundle is brought online. The gauntlet has been thrown, my next screen cam is going to show all this. And more…

My big takeaway for this session is “Today is good choking”.

I sat in on Marcel Offermans’, Karl Pauls’ (both from luminis) tutorial titled “Building Secure OSGi Applications“. Marcel and Karl provided a good incremental discovery approach to the tutorial, starting with the pre-OSGi 4.0 way of managing permission and moving quickly into the state of the art. The take-away from this tutorial for me is that—if you need security in your OSGi application—ConditionalPermissions and BundleSignerConditions are the starting point.

The basic idea is that you can specify a permission that says, “only grant permissions X, Y, and Z to any bundle that’s signed by so-and-so”. You can say, for example, that only your bundles (i.e. the ones signed by you) can write to the file system, or control who can import certain packages (I haven’t tried this last one, so I’m guessing that a relatively fine level of granularity is supported). There’s other kinds of conditions, including BundleLocationCondition which lets you grant permissions (curiously enough) based on the location in the file system of the bundle. You can use this condition to match a bundle’s symbolic name, assuming that the standard of using the symbolic name as the bundle JAR’s name is followed. My intuition is that this isn’t as useful as conditions based on signers, but this may change as I spend more time looking at it.

At this point, it seems that permissions can only be specified programmatically. It seems to me that creating a bundle that lets you specify permissions declaratively shouldn’t be too much work. Marcel stated that he’s not aware of any open source projects currently looking at this.

The tutorial worked mostly from the command line (using Ant to build) which I found a little disturbing. Naturally, I got caught up in making it all work using the PDE and a launch configuration within Eclipse so that I could (easily) use the debugger (Marcel suggested that I just attach the debugger to the application invoked from the command-line). It was actually pretty easy to get this running using the PDE, but did require some reconfiguration of the provided example projects.

I’ll have to incorporate this into an example.