The Callisto projects are now replicated to a handful of mirrors and are ready for download. Click here to start the Callisto experience.

For more excitement… see the video of Denis bringing the Callisto release to life.

I’ve been sitting on this idea for a while…

I finally found a picture that I can legally use while browsing around last night. The idea is a homage to an old Bloom County cartoon by Berke Breathed. For fans of the original, Opus is back.

I don’t know if anybody else noticed this, but there is a black line in this now-famous picture of Steve Northover embracing the NetBeans girls at this year’s EclipseCon.

I have to admit, that I initially found the line curious, but didn’t put too much thought into it. More recently, I’ve come to understand this line indicates that there has been some creative (and devilishly clever) photoshopping going on.

If you consider the other famous picture of Steve Northover playing guitar with Tim Boudreau, you’ll notice that Steve is looking away from the camera and is not wearing socks or shoes. Clearly, this is a hidden message indicating that Steve is dead.

My working theory is that the picture of Steve with the NetBeans girls was grafted together with some images taken of Steve in 1987 rocking out in the front row of a Bananarama concert.

No conspiracies indeed. Who are you really, “Steve”?

In response to my Friday entry, Jeroen asked about Eclipse application design; how do you architect an Eclipse application? It’s a good question.

I tend to fall back on classic patterns. As a start, I separate my application into multiple layers, employing the well known model-view-controller pattern. Typically, I’ll separate the layers into separate plug-ins. The “core” plug-in contains the model objects, and very often some kind of Facade to access the model objects. This “core” plug-in does not have any notion of user interface. Ideally, it also has no notion of storage (i.e. databases). One or more “view” plug-ins make use of the “core” plug-in to gain access to the object model and business logic to present a view of the models for the user. I tend to roll the notions of controller into the “view” plug-in.

This style of architecture is very similar to what you might find in a Java EE application: a web models (WAR file) contains servlets as controllers and JSPs as views; other JAR files contain the business logic and object model.

The Eclipse component model provides a great service in this style of architecture. By imposing a visibility model, Eclipse actively discourages the developer from including user interface code in the model (of course, real programmers can figure out ways around this). The collection of “view” plug-ins all have the “core” plug-in (and others) as dependencies: the views can see the core, but not the other way around. By encouraging this style of separation, the level of coupling in the code is reduced which makes the code far less brittle in the face of change and infinitely more reusable.

By separating out the model code in such a way that it can exist on it’s own, testing also becomes easier. Lately, I’ve been using fragments to build my test code (I used to just use another plug-in). Fragments are quite handy for building tests as they are merged together with the “host” plug-in at runtime and so can access the code being tested as though the tests were part of the host plug-in: you don’t have to expose any more of your plug-in at runtime than you want to and can still provide good test coverage.

A few paragraphs back, I stated something about ideally keeping storage or data access code separate from the core as well. In the beginning, I tend to put the data access code into the “core” plug-in. Over time, this code migrates out into its own separate plug-in to the point where the data access code is just another “view” of the data (in my object-centric view of the world, the user interface and database are just ways of looking at my objects).

So, at a high-level, there you have it. An Eclipse RCP application should be constructed of multiple plug-ins. Ideally, at the core of this set of are one or more plug-ins that constitute an application model that exists and works independent of any notion of user interface. Additional plug-ins provide a user interface along with any control glue required between the model and the view. And somewhere in there are still more plug-ins that provide data access.

All of the RCP examples that I’ve been discussing over the past few months do all of this. Besides reducing coupling and making reuse easier, I’ve also found that it makes the application far easier to extend; this sort of factoring of the application makes leveraging Eclipse’s extension-point mechanism a lot easier.

I don’t think that this sort of architecture has anything to do with Eclipse. It’s classic application development best practices. Fortunately, Eclipse encourages us to use them.

The Server Side Java Symposium wrapped up in Barcelona today. I sat on a keynote panel this morning titled “2010: A Developer’s Odyssey”. The basic idea was for the panel members to muse about what the ideal development environment will look like in four years. There was a lot of talk about dynamic language support and future innovation in AST-based editing (as opposed to source-based editing). Riveting stuff.

At the beginning of the talk, the moderator asked the audience: “who uses Eclipse”. Almost everybody (out of a total of 250 or so people) put up their hands (it looked like everybody to me, but I assume that there were a few folks who didn’t put up their hands). Later in the discussion, he queried about other Java IDEs. There were a handful of folks who use IntelliJ IDEA, and that was about it.

Eclipse is everywhere.

I presented my talk on Eclipse Rich Client Platform today at The Server Side Java Symposium in Barcelona. The talk started well and I think it ended strong, but I feel like it dragged in the middle. I decided that, given that the audience expects heavy technical discussion at a Server Side conference, I’d discuss the Eclipse extension point mechanism in more depth than I normally do. It’s such a powerful mechanism, and I think it’s a really important part of the Eclipse platform; but it sure is hard to talk about with a group that’s never built an Eclipse plug-in.

Strangely, I think that one of the hardest things for people to understand is the fact that all extension points are treated equally. There are no special ones; the extension points defined by “platform” code are treated the same way as extension points you create. I think that I may change the way that I talk about them.

I’ll probably start by talking about a handful of “built-in” extension points like popupMenus and actionSets. The discussion is relatively simple: “if you want to add a menu item to the context menu, you create an extension to the org.eclipse.ui.popupMenus extension point. You have to provide text for the menu, an icon, the name of a class that implements the behaviour, yadda, yadda, yadda, …”

Next, I’ll discuss how the extension point mechanism is totally open and that there really are no special “built-in” extension points. The so-called “built-in” extension points are just extension points defined in plug-ins that are part of the platform. Anybody can define new extension points in their plug-ins and those extension points are just as important as the others.

I’ll hook this discussion into the construction of domain-specific platforms and extensible architectures. The idea is that you can open your application to extension by defining your own extension points. I do this in all my RCP examples. In the eBay example, I defined an extension point that is used to contribute an auction provider (thereby making the extension provider completely pluggable). I also use numerous extension points in the task organizer and Sudoku applications.

I’ll test drive the changes to the presentation before I present at OSCON at the end of July.

I’m blown away by the number of times my demos have been viewed. Especially since most of them were done over the weekend. Don’t you people have lawns to mow?

I’ve got another one for you… Installing and Using the Eclipse Web Tools.

Again, there’s no sound. I’ve started playing with the format (I’ve leveraged Camtasia’s multiple flick feature), but the starting point is the same: you either start from the Eclipse SDK or from the Eclipse Platform Runtime Binaries. The demo goes through the process of installing the features, configuring the environment for XDoclet and Tomcat use, and then the creation and testing of a really painfully simple servlet.

Gather the kiddies: it’s good clean family fun!

I was on a bit of a screen demo’ing roll and built this little demonstration of how you go about installing and using the Eclipse Visual Editor. Again, there’s no sound, so don’t bother increasing your volume or yelling at the kids to quiet down.

The demonstration starts from a running Eclipse Workbench (The Eclipse SDK RC4) and uses the Callisto Discovery Site to download and install the feature at a speed that will astound and amaze you. The demo wraps up with the construction of a Swing JFrame using a GridBagLayout.

I made this little demo a few weeks back. It goes through the process of installing the CDT feature and then how you use it to build your first C programme. It starts from an already-installed Eclipse workbench–either the SDK or the Platform Runtime Binaries–and uses the Callisto Discovery Site to load the necessary features. I built the demo using Linux because you also need to have a C/C++ compiler installed and available before you can actually built a C programme.

I’ll apologise in advance for my lame C programming skills (the last time I wrote any C code as probably 1992).

Sorry… no sound. You’ll have to imagine my droning voice with this one.

Beatriz Iaderoza and Grant Gayed have contributed this article to Eclipse Corner on how to use the new virtual tables and trees added with SWT 3.2.