Step Up or Shut Up

So we're at it again, sigh...

It seems that the same people are commiserating the tragedy of the commons at Eclipse, at regular intervals, over and over again. Complaining is not a very good way to get what you want - I know one thing or the other about this as a father of three ;-). Complaining may work once or twice, but if you keep repeating the behaviour, people will stop listening to you.

Normally, I would just sit these things out but this time I feel compelled to add some oil to the fire:

• Diversity on e4: It is very easy to become a committer on e4 - that's one of the purposes of an incubator. Basically, all it takes is a believable email to e4-dev@eclipse.org that you would like to work on something in the context of e4, and you will be nominated as a committer. Still, IBM has most of the commits in the e4 project. Who do you think is to blame for that? IBM? Because it is investing in a project whose goal it is to bring innovation back into the Eclipse Platform?
• Diversity on the Eclipse Platform: The last example I know of where people or companies wanted to contribute to the Platform but were not received with open arms is from about two years ago, when developers from WindRiver complained that their contributions did not make it into the Debug and Resources components. Where are we today? Both these components have committers from WindRiver, and Martin Oberhuber, a WindRiver employee, is a member of the Eclipse PMC. By the way, are those new committers contributing to those Eclipse Platform components full-time? No. (Just to be clear - I don't want to pick on WindRiver at all: I think it's great that they are in fact investing in the Eclipse Platform, even if it's just a little, when many other companies that benefit from the Platform don't invest anything at all.)
  So, if you'd like to contribute to the Eclipse Platform on an ongoing basis, and feel that you are not "let in", please speak up so that we can fix the problem. I am pretty sure that this problem doesn't exist, and that instead the problem is more on the side of those who decide not to contribute, than it is on the side of the existing committers.
  
• Forking: As of lately, this is easier than ever. Eclipse projects are now mirrored as Git repositories, starting with those that are using CVS for the main development. Knock yourself out, and don't forget to make the source available if you are creating derivative works. However, I don't think this is going to be a solution to the "tragedy of the commons" problem. I do hope this will make it easier to create private branches when your development timeline does not align with the one at eclipse.org, and you need to just fix something now. I also hope it will make it easier for contributors in general to provide patches that don't go stale.
  By the way, the mirroring as Git repositories happened thanks to Denis and the webmasters at Eclipse, thanks to Shawn Pearce and the EGit and JGit team, and to a small amount thanks to Mike Milinkovich, the Eclipse Board of Directors, and your committer representatives on the board. If you are interested in details, see the bug Chris Aniszczyk opened on June 17th just after Doug Gaff and I were able to convince Mike Milinkovich and the Board (minutes) that it was important to make this happen.
• The Foundation is doing concrete work to help: Mike has mentioned some of the things that are planned for 2010 on his blog: "a branded Eclipse forge hosted elsewhere (e.g. IP Policy free), Git support for the whole community and major improvements in hosted build and test at eclipse.org." I believe that the Eclipse Foundation staff, and Mike Milinkovich as the executive director, are doing a pretty good job, and they are also actively trying to get more involvement by other companies and individuals for core projects at Eclipse. The board of directors even made this a strategic goal for the Eclipse Foundation this past June¹.
  

So overall, my comment would be "step up, or shut up". If you care about the future of Eclipse, pick a component or feature in one of the core projects that is critical for your use of Eclipse and help what you can. I would put at least the following in the "core projects bucket": Equinox, Eclipse Platform (with SWT, JFace, Workbench, Resources, Debug, Text, etc.), EMF, and GEF. If you think another project belongs in there, pick it instead and help there.

Now for the definition of "help", I would recommend that you focus on a narrow enough subpart so that you can follow along for the next little while (like, for example, a year). Spend some time on the newsgroup/forum, read and understand the code, watch incoming bugs, find out who is the current maintainer, contact them and let them know you are interested in helping, and so on. This does not have to take a lot of time, but there is probably a lower limit of perhaps one or two hours per week. Convince your manager that doing this is important for the company, since they have software products that rely on the component or feature in question. You can also argue that investing a little time will help improve your skills. In fact, the latter point is a motivation that works even if you don't have an employer, if for example you are a student, or self-employed, or just not employed at the moment.

What's in it for you? Potentially fame, when your name starts appearing in Eclipse source file headers, or in IP logs (which by the way are another good way to measure project diversity). You'll learn about "the eclipse way", the development process that allows us to ship on time and with quality, every year, for the last nine years. Finally, you'll have the warm fuzzy feeling that comes with ensuring the future of a core piece of technology that is being used by millions of users. Of course, you could help an Apache project, or Linux, or Mozilla, or on SourceForge or GitHub, but chances are (if you are reading this on Planet Eclipse) that your job indirectly depends on the future of Eclipse - not Apache, Linux, or Mozilla.


(Image © Zen Sutherland, http://www.flickr.com/photos/zen/241745451/sizes/o/, licensed under Creative Commons by-nc-sa 2.0)


¹ You have to read between the lines for this, not sure if newer board minutes have more detail. The June board minutes state: "In discussing the strategic goals of the Eclipse Foundation, the Board indicated that diversity on e4 was of strategic importance to the Eclipse Foundation. In addition, it was important to continue to grow a diversified revenue model. As a result of the discussion, these two concepts were introduced into the Strategic Goals of the Foundation." Since a strategic goal that focuses solely on e4 seems a little odd, this has been generalized to apply not only to e4 but to other platform-y projects at Eclipse, I believe the wording is "Ensure adequate resources are invested in the core technology platform".

OpenSocial (iGoogle) gadgets in Eclipse

Some of you may have seen this already, in the e4 M2 new & noteworthy document: We are bringing Eclipse and the Web closer together. This work, a collaboration between Benjamin Cabé of Sierra Wireless and myself, is happening in the e4 project, which is the incubator area where we work on new technology, mostly for the Eclipse SDK 4.0 release planned for Summer 2010. (Some of the technologies developed in e4 may make it into the 3.x stream¹ as well.)

Concretely, we are opening Eclipse for a whole new world of UI components called OpenSocial gadgets. You have probably seen gadgets in action already, on iGoogle homepages. You can find gadgets that, for example:

• display your Remember the Milk to-do list,
• show your Twitter feed (with updates every x minutes),
• provide your GMail inbox,
• show a calendar, or, most importantly:
  
• display the "cat photo of the day". :-)

Normally, gadgets would be hosted inside iframes on a web page. A web page that hosts gadgets, usually with the help of some server-side infrastructure, is called an OpenSocial gadget container. Many social websites are OpenSocial gadget containers - in fact, it looks like every social website except for Facebook is an OpenSocial gadget container - for example iGoogle, hi5, LinkedIn, MySpace, orkut, Friendster, Ning, XING and many others. Check out the OpenSocial web site and scroll down for the full list. Most (if not all) of these sites use the Apache Shindig reference implementation.

In Eclipse, OpenSocial gadgets are hosted as views. This is what it looks like:

More information, including how you can contribute, is available on this wiki page. You can also download e4 M2 and play with it, or install the feature into a 3.5 or 3.6 build as described on the wiki page.

I think this is really exciting, and potentially an important part of the future of Eclipse. Here is why:

1. It makes it easy to add a new view (or editor) to Eclipse. Just write HTML, CSS, and JavaScript, and you don't even have to know that the gadget is going to be hosted in an Eclipse application. All the usual web arguments apply - zero install, all you need is a URL, proper sandboxing, etc.

2. It brings Eclipse and the "Open Web" closer together. Web UIs are becoming increasingly important, and who knows, we may at some point want to run a full-blown IDE in a browser. But until then, we need a way to take advantage of the web without losing everything that we already have - supporting the existing Eclipse plug-ins is important for the forseeable future. By bringing the web to Eclipse instead of bringing Eclipse to the web, we can get the best of both worlds, if we can ensure that gadgets can become first class citizens in a desktop Eclipse application. (See 4. for what I mean by "first class Eclipse citizen".)

3. It can make Eclipse more social. At this point, our implementation does not support the "social" part of OpenSocial gadgets, but if we added that support, it could serve as another integration point for plug-ins, similar to how the common resource model (projects/folders/files) is an important "common currency" for IDE plug-ins.

4. The OpenSocial specification could benefit, too. We have ten years of experience with Eclipse as a platform or, as I like to call it, as a client-configured mashup platform. Users can start with a minimal platform, add a whole bunch of plug-ins and get an application where individual pieces work together seamlessly. (OK, I admit, it's not seamless in some cases, things don't always work together well, and if you add an insane number of plug-ins, Eclipse is slow and bloated, but I hope you get the idea.) I honestly don't know which other platform has come as far as Eclipse has in terms of integration of heterogeneous components. If you look at examples of the kind of integration and seamlessness I list below, only the first two are currently addressed by the OpenSocial gadgets specification. Many of the other "integration points" that we offer in Eclipse would make sense for OpenSocial as well, if the goal is to support more than a bunch of independent gadgets that sit next to each other on a web page. Here is a partial list of what we call the Eclipse Application Services a.k.a. "the twenty things":

• Editing preferences in a consistent way.
• A common mechanism for localizing strings.
• Providing and listening to the current window-level selection.
• Being able to start long-running operations, with progress reporting and the ability to cancel.
• Indicating unsaved changes and prompting to save on close.
• Common undo and redo operations.
• Persisting UI state (e.g. column widths, sorting, etc).
• Error reporting.
• Common dialogs for common tasks.
• Contributing menu and toolbar items to a shared area (global menu or toolbar), or even to other views and editors in form of additional items in local menus or toolbars.

For the full list in draft form, and more details, check out the Eclipse Application Services wiki pages. Ignore the fact that most of these wiki pages describe API in Java - it wouldn't be hard to specify similar or equivalent API in JavaScript as well. We still have to find out how best to interact with the OpenSocial community, and if they would be interested in taking their spec to the next level as hinted at above.

On the Eclipse side, our plans for the coming weeks and months are roughly the following:

• Complete and solidify our implementation, which currently has high duct tape content.
• Investigate if we can reuse parts of Apache Shindig to make our job easier.
• Offer Eclipse Application Services as so-called "features" that gadgets can (optionally) depend on.
• Write example gadgets that show the kind of integration into Eclipse that we'd like to see.

Do you have an idea for a gadget that you would like to see in Eclipse? Would you like to join the fun and become an e4 committer to work on this with us? Let us know on the e4-dev mailing list if you would like to participate, or send me a direct email. Bugs and enhancement requests can be filed in Bugzilla.

Plain old comments on this blog are welcome too, of course. ;-)

¹ - Similar to what Apache did with its httpd project and the 1.3.x and 2.x streams, we are planning two Eclipse SDK streams going forward - regular releases on the 3.x stream (3.6, 3.7, 3.8 ...) with a focus on stability, and a parallel 4.x stream with the innovative stuff.

Adventures into web UI land

To explore how easy or hard it would be to write a UI component using web technologies, and then integrate it as a first class citizen in Eclipse, I reimplemented the PDE "site.xml" editor for the 0.9 release of e4, using HTML, JavaScript, Dojo, and CSS.

I thought it would be interesting to document the design decisions that I made for this. Since my experience with web UIs is somewhat limited, you should take the following with a grain of salt. I did, however, work on something that could be characterized as an "IDE in a browser" for over three years (2001-2004), so I don't consider myself a complete rookie. :-)

Note that I won't talk about integrating the web UI component into Eclipse, this posting is just about the actual web UI component itself. The Eclipse integration is a related, but different story, that deserves its own post.

Let's start with a screenshot of the original PDE editor. It has two panes, a tree on the left showing features and categories, and a bunch of fields on the right with which you can edit the currently selected object in the tree. Depending on the type of object, the right side shows different fields, for example feature environments if the selected object is a feature, or category ID, name, and description if the selected object is a category. To add new categories or features, there are some push buttons on the right side of the tree.

We should be able to achieve a very similar look and feel with a piece of web UI, after all, the "flat look" of the PDE editors was an attempt to mimic the look of a web page.

The first important decision I had to make was whether to generate the HTML, pre-filled with the data, on the server side. This has the advantage that the resulting HTML can be made to (somewhat) work even if the web browser displaying it has JavaScript disabled. You would probably use a server-side template engine for this. If you follow the link, you can see one of the disadvantages of this approach - there are a bajillion template engines to choose from. Good luck with deciding which one! ;-)

But seriously, I had other reasons for deciding to let client-side JavaScript fill in the data instead. For example, this approach scales better because the "filling in data" work is done on the client, with the server doing less work because it only serves raw data. Also, it makes it easier to handle dynamic changes to the data on the client side because there is only one way of turning data into populated widgets. Development and testing is easier because you avoid a complete layer of the cake - you don't need to restart the template engine or reload the template every time you make a change, instead you change the .html or .js file and reload the page in the browser. Finally, this approach quite naturally leads to an interface between client and server that could be used by other kinds of clients as well (you get an API if you decide to publish and maintain it).

Oh and I forgot, it wouldn't be buzzword compliant - to claim you're doing Ajax means that you have to use JavaScript and XMLHttpRequest, and to be RESTful means that the server should serve raw data.

I started with the HTML and CSS first, leaving the client-server communication for later. My first goal was to get the right kind of "look". Many things are easy to do in plain HTML, for example input fields and buttons, and the header area that says "Update Site Map". There were two things that are hard (or maybe impossible) with plain HTML: making the two panes resizable by the user, and displaying a tree of objects. I decided to use Dojo for these two things, because I had a little previous experience with Dojo, and because it had been IP-approved for use by Eclipse projects. Note that I didn't use Dojo widgets for buttons and text fields, mostly because I didn't like their Dojo-styled look and wanted the "plain" look that you get from plain buttons and plain text fields.

For the resizable panes with a draggable splitter between them, I was able to use a Dojo BorderContainer, which is configured like this:

<div dojotype="dijit.layout.BorderContainer" design="sidebar"
   livesplitters="false" gutters="false"
   style="width: 100%; height: 90%;">

The tree is created dynamically from JavaScript as follows:

myTree = new dijit.Tree({
  id: "myTree",
  model: model,
  showRoot: false,
  getLabel: function(item) { /* code to return the label... */ },
  getIconClass: function(item, opened){
     /* code returning a CSS class for the icon */
  },
  onClick: function(item,treeNode) { /* ... */ }
});
myTree.startup();
dojo.byId("tree").appendChild(myTree.domNode);

This creates a tree widget based on the model you are passing in, and puts it under the DOM node with the ID "tree". Of course, there is more code than what I am showing here, but I hope that the few snippets I am showing give you enough context to understand the rest.

I initially ignored the server part completely and just hard-code some example data right in the JavaScript. This allowed me to rapidly test and develop the web UI in a browser. Actually, make that "in all the browsers I cared about". During development, I kept Firefox, IE, and Safari open to make sure it worked in all of them. Some of the things you'd like to do in CSS, in particular with respect to layout, don't work quite the same in all the browsers. :-)

Here is the result, opened in a standalone web browser:

My next decision was about the client-server communication. I decided to use JSON as the data transfer format, because, as you all probably know already, "JSON has become the X in Ajax" (quote: Douglas Crockford). There was a more pragmatic reason, too: the version of Dojo that I used was a bit older and didn't support trees backed by XML data. With a little help from Dojo, you can make HTTP requests without having to worry about browser differences.

There is only one thing that is not obvious: if the web UI is in a file like "site-editor.html" that references the necessary CSS and JavaScript pieces, then how does it know its "input", i.e. which resource to operate on? Somehow, the web UI needs to get to know the full path to the site.xml file. One widely used approach for solving this problem is to (mis-)use the "anchor" part of the URL that the browser points at. So for example, if the browser's URL is http://localhost:9234/pde-webui/site-editor.html#/myproject/site.xml then it will request /pde-webui/site-editor.html from localhost:9234, followed by an attempt to find the anchor named /myproject/site.xml in the HTML. Even though it won't find this anchor, the document.location object will contain the full information. This means that our JavaScript code can just get the value of document.location.hash and then make a corresponding XMLHttpRequest to get data from the server, which it then uses to fill the widgets. Once you know about this technique (which by the way has some nice properties with respect to the back button and the browser history), you will start to notice its use in many existing and widely used web-based applications. Like for example, https://mail.google.com/mail/#inbox, or http://www.facebook.com/home.php#/bokowski?ref=profile :-)

By now, if you are still following, we have a client-side web UI consisting of some HTML, CSS and JavaScript, that will access a server over HTTP to get the data that needs to be displayed. Let's now focus on the server part.

Obviously, we need a place to serve our static .html, .css, and .js files. The canonical choice for this is to configure Jetty accordingly. I am instantiating my own instance of Jetty and instruct it to pick a port number for me. If I know that the web UI will only be accessed from the local machine, Jetty can be configured to only accept connections from localhost.

For the RESTful interface, I implemented a servlet that

1. responds to a GET request with the data I need in JSON format, and that
2. accepts PUT requests when the user wants to save changed data.

In reality, the servlet does a little more (like e.g. authentication), but this post is already pretty long and I need to gloss over some of the details to not bore everyone to death.

Let me just add one more thing - how did I implement the part of the servlet that converts the site.xml file into the JSON format I needed?

The most obvious approach would be to parse the XML as a DOM and then generate JSON based on that DOM. Instead, I decided to use EMF objects as an intermediate "format". My idea was that by using EMF, the example code could easily be adapted to any data model that's already EMF based, and XML files (assuming they have an XML schema) could then be considered a special case.

If you have an XML schema, you can let EMF create an .ecore file for you (using the New EMF Project wizard). For my use case, I chose to not generate any Java code from the .ecore file, because the code that generates JSON works on any EMF model, using generic EMF calls. This means that it should be very easy to change the schema, or even to use the same code for completely different models.

Just to be clear, if you know that the format of your XML never changes, or if you want to minimize the external dependencies of your code, or if you enjoy programming against the DOM API ;-), or if adding EMF as another "layer" disturbs you, it's perfectly fine to not use EMF. Maybe it would even make sense to use XML on the client side as well.

Overall, I was pretty happy with the structure that I came up with and think that it can serve as an example of how to approach the task of writing a web UI component. And now I'm looking forward to your comments, especially ones that explain how I could have made better decisions!

JSR 330 (Dependency Injection for Java) passed!

Two days ago, JSR 330 passed its final vote, and we now have a standard way to annotate Java classes for dependency injection. Thanks to the spec lead Bob Lee, the JSR 330 expert group did its work in record time, in the open, and under one of the most permissive licenses.

Because of the transparency of the expert group work, it is no secret that I am representing IBM in that group. I even implemented the spec in order to understand it better, and made that implementation available as open source in the context of the e4 project, which is the place where Eclipse Platform folks can experiment with new technologies. (Btw, I intend to put javax.inject in Orbit for use by other Eclipse projects.)

I am happy with the current state of JSR 330 and am looking forward to working with the expert group on a planned maintenance draft that will define a portable configuration API. Because with such an API, it will be possible to reuse application code across different injector implementations.

Note that postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions. Similarly, IBM's votes on JSRs don't necessarily represent my personal positions, strategies, or opinions. ;-)

Embedding web UI components in Eclipse using e4

The demand for software that can be accessed through a web UI is increasing. We already expect software for occasional use (e.g. online shopping, banking, filling out forms, ...) to be accessible from a browser, without having to install anything locally. Over the last few years, more and more producticity applications (email, documents, spreadsheets, etc.) have become available through browsers as well. It is only a question of time until software development tools (at least for a certain class of uses) will have to have a web UI as well. In fact, a few browser-based IDEs already exist, such as Mozilla's Bespin project, and a very recent example: embed, a special-purpose IDE for embedded development.

At the same time, locally installed "rich client" applications, especially software development tools, aren't going to go away soon - there is a huge investment in the tools we have today, and I don't expect that all of this will be reimplemented using other technology just because web UIs are now the cool new thing to do.

So the obvious question is, how can we, the Eclipse community, prepare ourselves for the trend towards the web, while keeping our desktop users happy?

One approach is to keep the current programming model and just "make the stuff run in a browser". Fundamentally, this is very hard because the existing code we have today is not written with a client-server separation in mind. To a certain extent, it can be made to work though, and we have two examples of this at Eclipse, in form of the RAP project, and the experimental "SWT Browser Edition".

The basic idea behind RAP is to place all application and UI logic on the server, including all widgets and their state, and to render those widgets on the client in a web browser while sending user events back to the server. However, there are a couple of characteristics of RAP that limit its applicability: For example, the "stuff" you run in a browser will be a complete application as opposed to individual UI components, high-latency situations are problematic, and you cannot run application code on the client side. (I hope the RAP team will let me know in the comments if I got any of this wrong.)

The work on SWT BE "browser edition" is another take at the same problem, taking, if you will, the opposite approach: Client code (application and UI logic) makes use of the SWT API and as such can run in a desktop situation just fine. For "making it run in a browser", all the code is cross-compiled - to JavaScript for the Dojo port of SWT, or to ActionScript for the Flex port of SWT. So in a nutshell, instead of placing all application code on the server as with RAP, all application code ends up running on the client, in a browser. The obvious problem with this approach is that you still need code that runs on the server, to at least send data to the client and to receive updated data from the client, and that more often than not, you will end up with too much code on the client for execution. Of course, you could rewrite your existing code and ensure a proper client-server split, but if you are rewriting it anyway, why not go all the way and rewrite it using HTML and JavaScript?

For the e4 0.9 release, we have done the first step of exactly that - we rewrote or "cloned" an existing component using HTML, CSS, JavaScript, and Dojo on the client side. The idea is to gradually move certain components (not complete applications) over to use web technology, while still having these components appear in the desktop Eclipse client as first-class citizens. As a first example, we chose the PDE site.xml editor, because of its relative simplicity but also because it is a good representative of a whole class of form-based UI components in Eclipse. We wanted the end result to run in a regular browser, as well as an editor inside of Eclipse. Here you can see it running stand alone in a browser:

To make the editor work in a regular browser, it had to have a "real" server-side counterpart. Luckily, Eclipse already ships with an embedded servlet container, Jetty. This means that the web UI editor could talk to a servlet running in the same VM as the embedded browser widget rendering the UI. This is not unheard of at all - the Eclipse help system is taking the exact same approach.

However, just presenting the unchanged web UI in an embedded SWT browser widget - backed by IE if you run Windows, Firefox on Linux, and Safari on the Mac - is not enough. The editor would only be a first-class citizen in the Eclipse UI if, for example:

• you didn't have to authenticate to the web UI every time you open an editor,
• the editor signaled unsaved changes through the usual "*" in the editor tab, as opposed to an indicator in the editor itself,
• you can trigger saving your changes using the menu (File>Save ),
• etc.

In other words, the editor needs to make use of appropriate Eclipse APIs that connect Eclipse UI components such as views and editors to their context: the Eclipse workbench. One of the goals of e4 has always been to simplify the core APIs, and to make them accessible from other programming languages. So in a sense, we have started to make this real by offering JavaScript APIs that can be called by web UI components: to signal that they have unsaved changes, to provide a callback that will save those changes, etc.

Give it a try! After downloading the e4 0.9 SDK, start it up with an empty workspace and create an update site project (Ctrl+3, 'nusp'). Add some features and categories to it using the regular PDE site.xml editor, save, and then right-click on the site.xml file and use "Open With" to open it with the web-based editor. It will look like this:

Please leave comments if you have any questions. I will try to write up more about this in the next couple of days, going into more technical detail.

API compatibility matters

A few weeks ago, Palm has released an SDK called "Mojo" for their WebOS. They also offer Eclipse plug-ins that have been developed for and tested with Eclipse 3.4.2. I just read a short review of this Eclipse-based tooling and was happy to see the following:

The WebOS plug-in is supposed to officially work with Version 3.4.2 of Eclipse (code-named Ganymede). However, I was able to successfully run it on Version 3.5 of Eclipse (code-named Galileo) without any problems.

It makes me happy to see real-world reports like this. They confirm that you can run plug-ins developed for older versions of Eclipse on more current versions. In the Eclipse community, we almost take this for granted and sometimes tend forget the effort involved in pulling this off. Because when you think about it, compatibility is only achieved when both sides do a good job of enabling compatibility:

• On the Eclipse SDK side, we tend to think that we are doing good job of ensuring API compatibility between Eclipse releases, so that you can run older plug-ins on newer versions of Eclipse. Since Eclipse 1.0 (2001), we've had excellent rules in places around API compatibility, and if you want to read more I'd recommend you start at our "API Central" wiki page. More recently, we've automated a lot of the necessary compatibility checking in form of API tooling that ships with the Eclipse SDK. I haven't seen anything like it for other languages or environment yet, but would like to hear if similar tooling exists elsewhere. C#? ActionScript? Let me know in the comments!
• On the Palm Mojo side, the developers must have done a good job of only using documented APIs, and abiding by the contracts for those APIs. Because if you don't, all bets are off.

Here is a quote from the 2001 article "How to use the Eclipse API" by Jim des Rivieres, a recommended read for anyone developing Eclipse plug-ins:

As the Eclipse platform matures and evolves, it will be the API contracts that guide how this evolution happens. Outside of these contracts, everything is unsupported and subject to change, without notice, and at any time [...]. Client code that oversteps the above rules might fail on different versions and patch levels of the platform; or when run on different underlying OSes; or when run with a different mix of co-resident plug-ins; or when run with a different workbench perspective; and so on. [...] To those who choose to ignore the rules, don't say that you weren't warned. And don't expect much more than a sympathetic "Told you so."

Of course, in reality, life is never as easy and black-and-white as software developers would like it to be. Sometimes, the existing API doesn't work for your particular case, or there is no supported API at all. In these cases, however, you need to realize that by calling internals, you are assuming technical debt. The idea behind this metaphor, created by Ward Cunningham, is that you have taken a shortcut and need to pay up later, either in form of interest payments or paying back the principal. In concrete terms: Whenever a new version of the plug-ins you depend on comes out, you have the cost of testing that your code still works, and the cost of adapting to any change that may have broken your code. This is a recurring cost, hence the term "interest". If you want your code to run against both older and newer versions of your dependencies, the interest payments are much greater, because the problem is much harder. Often, you will need to use Java reflection to guard your calls to internals. Alternatively, you can pay back the "principal" at a later point in time, when the necessary API has been added, and get rid of your debt. You did file an enhancement request to get that API added, didn't you? Because if you don't, you'll be bound to pay interest forever!

Every now and then, I encounter people who are hoping to get away without paying either interest or principal. And that's after our collective experience with how schemes based on trading debts can take the whole economy down! :-)

Thank you!

I am looking forward to attending my first Eclipse Board meeting on Monday. This first time, I will be a guest since my term of office starts in April. Unfortunately, I can only attend the second half because I am co-presenting a tutorial in the morning. Sorry about that, it won't happen again. ;-)

Thanks to all who voted!

RCP Mail 2.0

Come to our EclipseCon 2009 tutorial (Monday March 23, 8:00 - 12:00) if you would like to learn about best practices for data binding, commands/handlers/contributions, and the common navigator. Bring your laptop with a copy of Eclipse SDK 3.5 M6 for the hands-on excercises!

Three RCP practitioners, and three Platform UI committers for a total of six people will help you understand and build RCP Mail 2.0. Should be fun!

2009 Eclipse Board of Directors

You have probably seen Mike's email - the elections for committer representatives for the Eclipse Board of Directors is now open.

Rather than explaining why you should vote for me :-), I thought it would be useful to summarize the key election facts:

• You are voting for a one-year term starting April 2009. Voting is open as of today, for three weeks until March 13, 3 pm Eastern time. Check out the committer candidates and their vision statements.
• To vote, check the email you received from emo@eclipse.org on Feb 20, 2009. It contains the URL for voting, as well as the required voting password.
• The Board will have 24 directors, as follows:
  • Sixteen directors for the strategic members, one seat per member.
  • Four directors from "sustaining members". There are nine candidates, and sustaining members (companies) get to vote. This is the old "add-in providers" category but generalized to include "enterprise members" in the future.
  • Four directors representing the committers. There are six committer candidates.
    
• Each committer has one vote. Here are some important details:
  • Committers who are employed by a member company can go ahead and vote. Note though that all votes from one company will be collapsed into a single vote.
  • Individual committers, if they have not done so yet, must sign a membership agreement in order to be able to vote. To understand why this is required, read this page, then read this page to make sure you fill out the form correctly. No voting privileges without signing the form!
• In previous years, turnout was pretty low - for example in 2008, only 148 of about 1,000 committers cast their vote. More votes will add weight to the positions of the committer representatives, so please vote now!
  
• There is more than one Eclipse Board of Directors, so be careful not to confuse the different board elections. ;-)

Eclipse in the Cloud

About a year ago, at EclipseCon, we showed a demo of how the Eclipse IDE could look like if it was browser-based, talking to an Eclipse server "in the cloud". The reactions were lukewarm: "Looks cool, but why would I want to run an IDE in a browser?" "I have yet to see web enabled IDEs as an industry trend".

This industry trend is now starting to happen.

On Thursday, Mozilla and their new developer tools lab launched Bespin, an "experiment proposing an open, extensible web-based framework for code editing". Within a few days, 30,000 people logged into their public server, 400 people joined their discussion group, about 50 bugs were filed, several of them with patches, and many articles, blogs and even a Wikipedia entry were written. Congratulations, Ben and Dion of Mozilla (and Ajaxian fame), on the successful launch!

We looked at Bespin and asked, wouldn't it be great if Eclipse could play in this space too? Wouldn't it be cool if we could implement a Bespin server using Eclipse plug-ins that already exist?

Well... that Eclipse-based Bespin server is available now, after two days of development!

Simon Kaegi and I locked ourselves into a room and just implemented it. Today, we are declaring success, and are sharing the code as part of the e4 project with anyone interested. If you would like to give it a spin, check out this wiki page.

The Eclipse IDE, as you know it, is an OSGi-based application, and is built entirely out of components (called plug-ins or bundles). Many of these components can run headless, on a server, such as the underlying resource model, the incremental Java compiler, etc. Using the headless components, it was very easy to implement the Bespin client-server API. Like Mozilla's Bespin server, our server supports browsing files and folders, and editing files. In addition to that, we implemented extra features such as showing compile errors and warnings, and checking out projects from CVS servers using anonymous CVS.

Bespin already shows a lot of promise at this early stage. It consists of a surprisingly fast code editor written in JavaScript using Canvas, a file browser, and an emacs-like command line interface for issuing commands. There are two backend implementations provided by Mozilla, one in Python, and one in Java, and the browser-based client talks to the server using a RESTy API. Here is how it looks like:

If you would like to play with the Eclipse Bespin server, or work with us on it, check our wiki page. If there are any questions, hop on IRC, where we can be found on #eclipse-e4/irc.freenode.net or #bespin/irc.mozilla.org as borisb6i and skaegi.

P.S. Mozilla has a cool-looking and fast client, and Eclipse has a lot of experience with IDE features, and good amounts of code that can run headless. Sounds like a great opportunity for collaboration, doesn't it? Well, thanks to Mike and the Eclipse Foundation who organized it, and Dion and Ben who are investing their time and some of Mozilla's travel money, we will have an in-person meeting on Thursday, in Ottawa, to talk about this. These guys are moving fast!

Bundle Marketplace: +1

I fully agree with Gorkem Erkan that the Eclipse community should seriously consider building a bundle marketplace. In fact, I recently had the same idea (independently) as you can see here on Twitter.

In the Eclipse context, that bundle marketplace would probably consist of multiple overlapping sub-markets... with every Eclipse-based application defining a sub-market. For example, bundles that work with the Eclipse IDE, bundles that work with the Flex IDE, or the SAP IDE, or with IBM's Rational tools such as Team Concert. Also, at the RCP level, vendors could offer a basic application for free and offer upgrades as additional for-pay bundles.

I think this an exciting idea. What do we need to do to make it happen? Would the Eclipse Board of Directors support this? Which members of the Eclipse community (other than Kent Beck ;-) ) would benefit the most, short-term?

Looking forward to your comments.