We just posted a great new tutorial titled “Building Project Facets” by Konstantin Komissarchik of BEA Systems on Eclipse Corner. If you want to know what facets are, and how you can use them to extend the capabilities of the Web Tools Platform, this tutorial will set you straight.

I’ve also recently published an article, “Eclipse RCP: A Platform for Building Platforms” on ONJava. I excerpted bits of this article for my position paper for the Rich Client Applications Symposium at Eclipse Summit Europe.

Yesterday, I submitted my position paper for the Rich Client Applications Symposium at Eclipse Summit Europe. My position is basically that Eclipse Rich Client is good, components a la Equinox are king, and that folks should be building domain specific extensible platforms using Eclipse Rich Client technology. To be completely honest, this is my first position paper, and I’m pretty excited about it. So excited, that I’ll likely submit another one for the Eclipse Modeling Symposium.

Frankly, I’d love to attend all the symposia. Test Driven Development for
the Embedded Systems Space sounds like a lot of fun. I’m a big fan of test driven development (though I have to admit that I didn’t enjoy Kent Beck’s book on the topic as much as I’ve enjoyed his other work) and a big fan of the embedded space. Unfortunately, I’m too far behind on the embedded side of things to have a position other than “I think it’s all really cool”; that, and the symposium conflicts with the Rich Client one.

Equally cool sounding is the Server Side-Eclipse Symposium. I’ve been building server-side applications using Java for about a decade now, so I have a few opinions on the matter. Unfortuantely, this one also conflicts with the Rich Client one. Too bad.

I’m getting excited about the summit. It should be a lot of fun. Fun always happens when Ralph is around…

On a side note, I believe that I’ve exceeded my record for link density in a blog posting. I’m working toward having a blog composed entirely of links…

I needed a good calendar widget, so I took a look around. There are quite a few calendar widgets out there for Eclipse, but none of them did quite what I wanted. I looked at modifying one to better suit my requirements, but it turned out to be a lot harder than I had hoped. Naturally, I saw this as an opportunity to build my own.

I have to admit that there’s another reason for building my own: I really wanted to. I was in a mood to build a widget and this seemed as good a thing to build as any. I built the widget using standard SWT stuff. The initial implementation is derived from code contributed by Bahadir Yagan in bug 19945, however little of the original implementation remains.

Here’s what it looks like:

The calendar can be used either directly or as a drop-down. I spent a lot of time trying to get it work right with the keyboard; so the tab and arrow keys work the way that I think you’d expect. I’m sure that there’s more that it needs to do, and so I welcome your feedback. At very least, I need to do a little consolidation and commenting; while I like to think that my code is self documenting, I’m pretty sure that it’s not…

If you’re interested in taking a look, you can access it from here:

:pserver:anonymous@dev.eclipse.org:/cvsroot/org.eclipsewww/evangelism/samples/datepicker/code/org.eclipse.swt.extensions.datepicker

There’s a Main class included that demonstrates the operation of the widget.

One thing that I’ve been thinking about lately is ICU support. The current implementation doesn’t use ICU4J. Instead, I just used the standard Java classes to figure out how to build the calendar. My next step is to convert it over to use ICU4J and try to sort out how to handle arbitrary calendars (and there does seem to be a lot of them). The big challenge for me is that I know very little about other calendars. Okay… I know nothing about other calendars. If you’re curious to see what I’m talking about, browse the hierarchy for com.ibm.icu.util.Calendar to see all the different subclasses (each supporting a different calendar).

Assuming that I’m smart enough to sort this out (Maria is helping, so there’s a good chance that something good will come from this) I’ll let you know how it works out.

I’m finishing up the materials for the Callisto Bootcamp that I’m running at Eclipse World. I thought it might be a good idea to do a little expectation management for those of you who are planning to attend.

Here’s the description as found on the conference program:

The Callisto launch of Eclipse 3.2—10 projects coming together with a massive simultaneous update and release—is unprecedented in the software tools community. For most Eclipse users, from committers to enterprise IT staff, Callisto will make a profound impact on every aspect of software development.

This tutorial, for experienced Eclipse developers who are currently using Eclipse 3.1, will deep-dive on the new features and innovations in each of the 10 projects that make up the Callisto Simultaneous Release. By attending this class, you’ll gain a unique perspective on these projects, not only about the individual new functions that they offer, but how they integrate together to advance the entire Eclipse ecosystem. Everything you want to know about Callisto—you’ll find it here.

Based on the text of the first paragraph, I’ve decided that the tutorial will focus on the use of the Eclipse projects by enterprise IT staff, rather than plug-in developers. I think this is reasonable.

The second paragraph suggests that the tutorial is for experienced Eclipse developers. I’ve made the materials with this in mind. However, I expect that there will be at least a couple of folks who don’t have this experience at the tutorial (this always happens), so I’ll plan to be dynamic.

The one part of the second paragraph that really bothers me is the use of the term “deep-dive” (I really should have considered this before accepting the abstract). I don’t think it’s possible to do a really deep-dive in just one day and have it provide any real value. What I’ve opted to do instead is go through a couple of usage scenarios that will expose folks to as many of the key function points of each of the projects as possible. In that regard, I don’t know how well the “Everything you want to know…” line will hold up. Hopefully, you’ll at least get a good start on many of the key features so that you can go home and get some real work done. There are a lot of other talks at the conference that will provide deeper insights into select topics.

The tutorial revolves around my current facination with Rich Client Platform. It starts with the construction, deployment, and testing of a web service using the Web Tools Platform (WTP). It then moves into the construction of an RCP application that works as a client for the web service, using the Visual Editor (VE) to create a couple of user interface components.

I’m leaning on the existing integration of the projects for much of the exposure to Callisto. For example, in order to do anything fun and useful with BIRT, you need to use Data Tools (DTP); to play with the Graphical Modeling Framework (GMF), you need to use the Eclipse Modeling Framework (EMF) and Graphical Editing Framework (GEF).

I’m focusing the use of Test and Performance Tools Platform (TPTP) on profiling the work built in the previous examples.

To be honest, I haven’t quite figured out how to showcase the C Development Tools (CDT) while honoring the “integration” tone in the description. I saw a pretty cool demonstration of how CDT can be used to manage an arbitrary tool chain that has nothing to do with compiling C code. If I can sort that stuff out in time, I may include it. It’s either that, or “Hello World” in C.

I think it’ll be a decent tutorial. I hope that you enjoy it.

Yesterday, I introduced International Components for Unicode for Java (ICU4J) by describing how you can get rid of it. I feel pretty about about that, because ICU4J provides goodness that’s too important to simply dismiss. If you’re building applications for an international audience, you have to get this stuff right.

I spent a few minutes today browsing around for a definitive list of reasons why ICU4J is better than what is provided by the standard Java libraries. So far, I haven’t been able to find that list. What I did find is a few examples of where ICU4J shines.

Consider the following example:

NumberFormat format = NumberFormat.getCurrencyInstance();format.setCurrency(Currency.getInstance(”JPY”));System.out.println(format.format(4.0));

With ICU4J, the output of this is “¥4″; using the standard libraries that ship with Java 6, the output is “JPY4.00″. Very different results. I’m no expert on international currencies, but a cursory review of the web shows me that the former is more common/correct (the use of the proper symbol is a dead giveaway). You can coerce the number of decimal points using the setMinimumFractionDigits() methods.

As noted in the Eclipse Wiki, ICU4J was adopted by Eclipse 3.2. ICU4J provides “more comprehensive support for Unicode, software globalization, and internationalization” than the standard java.text libraries, but comes at a cost. ~3MB to be inexact.

The functionality provided by ICU4J is great to have… if you need it. But one of the problems with this is that 3MB can be a lot when you’re building an RCP application and you don’t particularly care if all that software globalization stuff works exactly right. You can’t just remove the plug-in since it’s required by the platform code; but you can replace it with a much smaller plug-in (~100KB) that calls through to the java.text classes. You can download this from the same place you downloaded your RCP target (here for Eclipse 3.2).

I just reviewed the programme for the iX conference that’s coming up in November 2006. There’s a lot of Eclipse activity at the conference, including:

• Kai Tödter is holding a tutorial on Eclipse Rich Client Platform
• Richard Schwaninger is presenting Milchkuh Eclipse (Migrating Legacy Applications to Eclipse)
• Kevin Parker is presenting on ALF
• Andy Bosch is presenting Eclipse und JavaServer Faces
• Dr. Berthold Daum is presenting OSGi und Equinox: SOA im Kleinen
• Wayne is presenting on Eclipse RCP
• Ralph Mueller is presenting on Callisto
• Martin Lippert is presenting Spring und Eclipse Equinox kombiniert (Spring and Eclipse Combined)
• Dr. Axel Böttcher is presenting Eclipse in der Hochschul-Lehre (Eclipse in University Teachings)
• Jochen Krause is presenting Eclipse and Ajax

The title of this entry comes from a translation of the abstract for Richard Schwaninger’s talk. I’m really curious about this talk. I’m going to have to break down and learn German just so that I can attend (and understand) the topic.

I’ve updated the Eclipse Conferences page on the wiki to reflect these talks. If I’ve missed something (or if you’re presenting Eclipse topics at some other conference), please update the wiki.

Ben Walding has put together a page that contains all the icons contained in the Eclipse CVS repository. It’s a handy resource for finding just the right icon. They’re all released under the EPL, so you can actually reuse the icons (subject to the terms of the licence).

See here for a discussion of the page, including a description of how it was/is generated. Click here for the icons themselves.

You may recogize a few of these icons from the eclipse.org website. I know that Denis uses them on some of his pages.

This article illustrates how the EMFT OCL parser/interpreter technology adds to the value of EMF/JET code generation as a foundation for model-driven development (MDD). We will see, with fully functional examples, how a metamodel can be generated from an Ecore model without requiring any post-generation custom code, including complete implementations of invariant constraints, derived attributes and references, and operations.

Thank you to Christian W. Damus of IBM Rational for contributing this article.

Chris took me to task after this posting, exposing an important part of the Eclipse Corner publishing process: if things seem to be stalled, poke me (either directly or with a bugzilla comment).

Sometimes the process of getting an article published on Eclipse Corner is very time consuming. It all depends on what else is in the queue. When an article in the queue has already been edited and peer-reviewed by recognized experts in the field, publishing it is easy. However, when that edited and peer-reviewed article is behind an article that needs a lot more care and feeding, I very often don’t get to it as quickly as I’d like.

In this case, an friendly virtual smack in the back of the head works nicely.