Hotel Europe in Amsterdam!

As my vacation trip had a stopover in Amsterdam, I was pleased to notice that they named a hotel after Eclipse's latest and greatest release :-):

I need YOU to help Install/Update!

When it comes to Install/Update, I have seen the future and the future is rosy. At least that's what Pascal 'LeNettoyeur' led me to believe in the shuttle from Santa Clara to San Francisco airport after this year's Eclispecon. I am still not convinced that 'features suck' as Ed Merks likes to yell when protected by the Eclipsecon crowd (even he expressed concern that they may end up with the same 'sucky' thing with a different name :-). Nevertheless, I am sure that our Equinox friends will come up with something new and shiny and that it will catch the world by storm almost as much as OSGi did.

But let's take our eyes off the future and focus on the here and now. While we are dreaming (or should I say 'provisioning') new Update dreams, the old Update still needs to work and tie us over, or the new Update will be crushed by the unrealistic expectations before the birth pangs subside. There is Europa to ship, new features to post, patches to publish for all that brilliant software that was bug-free when you unleashed it on the unsuspecting public. Unfortunately, Install/Update is down to one active committer (yours truly), and he is a manager with a full plate. That's as if we are down to 0.1 committer with a short attention span :-).

As I am typing this, Alex Blewitt ran away with the prize by blogging about this first. I am not going to out-Alex him but here is the plan for a few good men (or women - we are equal opportunity here :-):

1. Take a look at the Update inbox (using this query will help)
2. Pick a bug that you would really like to see fixed and that has enough steps to be reproducible (but call it first so that others don't investigate the same problem)
3. Pick a fairly recent build (M6+) and set it up for Update development using these instructions (read under 'Feature-based self-hosting')
4. Try to pinpoint the problem; if you feel confident, try to fix it
5. If it seems to work, post a patch to the bug report, but be diligent - we want to fix existing problems, not create the new ones, right?

What's in it for me, you ask? You can make your code a proud part of Eclipse Platform (names and emails of contributors will be prominently displayed in file copyright notices). You can get a high from fixing a hard problem. At the end of 3.3, we will create an 'Update Hall of Fame" with pictures and short bios of top Update contributors. Finally, you will get to help yourselves by fixing problems that affect your own projects and components (he is looking at you, Mylar :-).

Last but not least, you will learn the whole problem domain of installing and updating bundles. When the time comes to switch to the new and shiny Equinox Provisioning, you will know what works, what doesn't, what you like and what is, to use Ed's immortal words, sucky.

API prime directives

In my recent tearful apology to the victims of the M5a build and their families, I made a reference to the Eclipse API prime directive that deserves further explanation. The accurate quote is:

API Usage Assumption: Every aspect of the API matters to some Client.

This quote comes from a seminal document written by Eclipse veteran Jim Des Rivieres who was in his time known as 'the API Police'. He struck fear in many a component lead when the time came to inspect the APIs before the freeze. Jim is now busy doing other interesting things (although he still lovingly prepares Eclipse New&Noteworthy for the milestone builds), but I encourage every committer to frequently come back to the said document, particularly when she prepares for the major API surgery (note from the revision history that the document has been kept fresh, most recently updated to include rules related to JDK 1.5).

Read the document and you will learn how to walk the razor-thin line between the API bliss and the M5a.

Forgive me, community, for I have caused M5a

In life of every committer comes a time that separates boys from men (apology to my female co-committers - I am only using this for the dramatic effect). A committer comes of age when he/she breaks the build for the first time. Another milestone that only the chosen ones reach is to cause an M5a build.

How can one reach such a lofty goal? It takes years of experience, ever increasing responsibilities that compete with the proper testing time and most importantly, a blissful disregard for the Eclipse API prime directive: Every API matters to some client.

In M5, we have reworked the UI Forms. A color that was used in the past is no longer needed. I deprecated the color key but made a mistake of not leaving the color by that key around for those who want to use it. You can read all the embarrassing details in the bug 174441. Who knew people find the color Forms use to paint the section title gradient useful for other interesting purposes.

What can I do to top this? I have never caused a rebuild of a GA build. But something tells me my commit rights will be wrestled away from me before I manage to achieve it.

Have we crossed the networking Rubicon?

Here's what happened to me the other day: I was happily working in my basement office when my visiting mother-in-law decided to call all the people in her phone book, one by one, from the main floor. She did it from a wireless handset that works on 2.4MHz. My wireless access point works on the same frequency, and in the battle that ensued the access point lost. Without the connectivity, I decided that I cannot do anything useful and chose to continue after lunch, or after my mother-in-law reaches the page 'Z', whichever comes first.

Beside the potential 'Everybody loves Raymond' moment, where am I going with this? The point is that I was not able to do anything useful without the network. This issue came to the head a few days ago when the UA committer Curtis D'Entremont and myself discussed the new remote help feature in Eclipse. It allows you to put all your help content on a remote server and still have the same great experience without the megabytes of documentation on your hard disk. We were trying to work through the scenario of remote help users that lost connectivity.

We came up with some great technical ideas but in the midst of it I remembered the mother-in-law incident. Should we even bother? Can you do anything useful without the connectivity any more? Have we crossed the networking Rubicon?

Now this is understatement

Being with the Eclipse project for a long time, I know well that Eclipse developers are not very good at tooting their own horn. We tend to just assume this is part of our job and make things look almost too easy.

Today I visited Steve, the daddy of the SWT team and he gave me a demo of Eclipse on Vista. The buttons that shimmer, the text fields that glow with anticipation when the mouse moves closer, the tree view animations, the works. It all looked great, fully native and had great performance.

I expected to see a number of entries in M5 New & Noteworthy to properly celebrate this event. Instead, this is what I found:

Note that the Win32 port of SWT continues to work well on Windows platforms and fully exploits the new look and feel of Windows Vista.

Have we come to assume that SWT 'just works' for so long that we don't see a great achievement when it smacks us on the head? I for one will follow Wassim's suggestion and say the following:

Thank you, Steve and the SWT team!

The first 2000 pixels

You know certain words are definitely lame when you hear your parents use them in everyday speech. Consequently, when IBM managers peek over their developers' shoulders and get a really novel idea to start a blog, you know it is time to create a new thing (preferably with an age limit). However, armed with a complete lack of self-awareness that is typical of managers and older people (sign me up for one of each), I decided to stay the course. After all, I can write a boring blog like the best of them.

The title of the blog and the matching header I painstakingly selected from a list of templates should reflect that I care about pixels. My several prior lives as a developer in IBM somehow always revolved around the UIs. I am the proud founding father of JFace before it was made part of Eclipse, and one of the original members of the Platform UI team (and I have an 'Eclipse Founder' shirt to prove it). I am also the father of PDE (as you can see, I am big on parenting), but all the damage I have done is now systematically rectified by the current PDE owner Wassim Melhem. As Scott Adams would say, since then I have been moved to an area where I can do the least damage - the management. The only sandbox I can play in to earn my developer stripes are now the UI Forms.

UI Forms started in PDE and many people still think they are a part of it. I don't blame them, since I used PDE as a show case for the technology. However, UI Forms are now completely standalone and are sitting much deeper in the stack - as an optional RCP plug-in. To me, they have it all - all the pixels I can eat, the excitement, the sexy (if you don't believe me, believe the blogger Chris Aniszczyk and one of his recent posts). And this is a great time to be in Forms, being recently refreshed and with all the new goodies that you can read about in the Eclipse 3.3 M5 New & Noteworthy (at the time of writing, M5 has not been posted yet, but my pent up creative juices cannot wait on the Eclipse process to play itself out).

And now, the $5,000,000 question: why should I add this blog into my bulging feed aggregator? Because: 1) you like Eclipse, 2) you like sexy UIs and 3) you understand that UI Forms can get you there if only you could ask the guy who wrote that code how the darn thing works.

And who knows, maybe, just maybe, I may be able to share a pearl of wisdom beyond the pixels every once in a while. They say old people are wise. That's a lie and you know it but I am willing to play along.