On Model-Based Modeling Builds...

In principle, I think most people agree that builds should be a shared responsibility, i.e., everyone should be equally able to do builds and the effort to do so should be equally distributed. Unfortunately, equal effort can sometimes result in nobody doing anything at all, because hardly anybody wants to! Trying to do the right thing in this context has launched many an accidental career in release engineering. So the best we can do is make the build effort as efficient as possible, giving everyone less reason to complain.

This has become essential for the Modeling project, which now has roughly sixty active sub-projects, many of which are one or two committer efforts with no way to justify a full-time release engineer. With that in mind, the Modeling PMC has recently decided to standardize on one build engine - Buckminster (often affectionately referred to as "Bucky") - for all of its projects, starting with the Helios release.

Why standardize? The obvious reason is to spread the joy of supporting build infrastructure across multiple projects. Less obvious, but no less important, is our not-so-distant goal of having a single build chain that can support true continuous integration for the entire Modeling stack, which should be much simpler if all of the builds are using the same technology.

Why Buckminster? The people and technology were familiar, so that was obviously a factor. But we tried to make as objective a decision as possible. Key considerations were the following:

• CDO and Teneo, having independently Buckminsterized last year, were enthusiastic supporters and made a strong case for the benefits.

• Unlike the alternatives, Buckminster is model-driven (it uses EMF). This makes it a no-brainer for us modeling zealots.

• We wanted to be able to reuse existing metadata, which is an advantage that Bucky has over Maven alternatives.

• Having a build that runs the same way in a developer workspace as on the server makes it much more efficient to spread build responsibilities across the teams.

• Adopting Buckminster gets us a step closer to using b3 (Buckminster will soon be supported as a build execution engine for b3), which we think is the future.

• Last, but not least, someone (i.e., Cloudsmith) stepped up to do the work!

Upon closer inspection, Buckminster had a few holes that needed filling. Support for automated build identifier generation/insertion, CVS tagging, and dependency version range management were non-negotiable for build slackers like Ed Merks (not to mention the rest of us mere mortals), and automated build promotion via Hudson was also highly desireable. So we rushed these changes through in time for Helios.

The effort of migrating from various older build systems (PDE Build, Athena, and variants) was not inconsequential. However, it ended up being relatively painless. One reason I can say this is because Michal Ruzicka (Buckminster committer and my colleague at Cloudsmith) did pretty much all the work. Michal was able to Buckminsterize most of the key Modeling projects in roughly a month of effort, which was pretty amazing, all things considered. Thanks again, Michal!

The first Buckminster build of EMF went live with M7 two weeks ago and the many other Modeling projects will soon follow. We'll be cutting a few key projects over as Helios heads toward completion. A number of others have chosen to postpone switching until just after the Helios release.

We'll send out periodic updates as the individual projects adopt the new build system over the coming weeks, so stay tuned for more details. In the meantime, if you want to hear more about what we're doing (and how), let us know!

On Google I/O...

I'll be out at Google I/O on May 19 and 20, talking up the work we've been doing with EMF on GWT and just generally learning more about all the great Google technologies we depend on.

Regarding EMF support for Google Widget Toolkit, we hope to have a working implementation of full modeling support for GWT applications before too long. Ed has been hard at work on this, and we'll soon have optimized object serialization between client and server, and a generic GWT editor for EMF-based models. We think this work will be really useful for GWT development once it's done.

With respect to other Google technologies, Cloudsmith is particularly interested in App Engine and BigTable; we're using them now but still coming up the learning curve. Next after that is Wave, which we'd like to use but doesn't seem quite ready for prime time. We're hoping/expecting to see a renewed Wave commitment and inspirational roadmap from Google at I/O next week.

Planning on being there? Let me know if you'd like to meet up!

On Where We're Using EMF...

Where are you using the Eclipse Modeling Framework (EMF)? I've blogged recently about how perhaps the "E" in EMF ought to stand for Extensibility. More and more, I wonder whether maybe it should stand for "Everywhere" instead. While many feel a burning need to bring the Web to Eclipse, at Cloudsmith we see things a little differently. We see big potential in leveraging the great technologies at Eclipse in new and interesting ways (and places!), one of which is to bring Eclipse (and, more specifically, EMF) to the Web.

When EMF made its debut at Eclipse some eight years ago, it was a framework for developing IDE-like applications. Then, it followed the lead of the Eclipse platform and expanded its reach to support Rich Client Platform (RCP) applications. Earlier in the Helios release cycle, we added support for the Rich Ajax Platform (RAP), which - thanks to the RAP folks' great work, particularly support for "single sourcing" an application - can almost be treated as a variant of RCP.

With Helios M7, however, EMF moves past the boundaries of the Eclipse platform, and desktop applications in general, by adding support for the Google Web Toolkit (GWT) as a new application runtime. We've done this by formalizing the EMF code generator's notion of a "runtime platform" through an enumeration. Platforms that previously were only implicitly supported - 'IDE', 'RCP', and 'RAP' - are now explicit enumeration literals. And now we've added a new literal for 'GWT'.

So, what does this mean? Well, depending on which runtime platform you choose in your generator model (and which platform you're targeting), you'll get a different result when you generate your code. For IDE and RCP, the only difference is in the editor (since RCP comes with certain limiting assumptions). With RAP, your edit and editor code isn't all that different from RCP, except that you'll have the ability to run against alternative versions of EMF's runtime UI plug-ins, which have been customized for RAP.

In the case of GWT, however, when you generate your model and edit code (support for editor and tests will come over the next few months), you'll be targeting an entirely different EMF runtime, tailored to be translatable into Javascript modules and to leverage the capabilities of GWT (RPC serialization, localized message resources, image bundles, etc.).

Ed and I will have more to say about the technical details of this new runtime over the coming weeks. In the meantime, you can refer to the New and Noteworthy page for Helios to help you get started with developing EMF-based applications for GWT!

On Looking Good...

Appearance isn't everything, but it certainly goes a long way, especially for things that are inherently visual. In light of this, the MDT Papyrus project is about to provide some new eye candy for its users. The project already has an impressive logo, but now they've made some fresh new icons for UML model element types. The Papyrus project lead, Sébastien Gérard, created a clever mosaic to show them off - see below. Let us know what you think!

On Noteworthy Pairs...

Phew. I've finally caught up after the frenzied activity of the past few weeks and posted a New and Noteworthy entry for the M6 milestone of EMF. If you attended the EMF tutorial or RAP BoF at EclipseCon, or perhaps saw Ben's blog post (gotta love the title of that one!), you're probably already aware of a great new enhancement that was added to EMF, thanks to generous sponsorship from another one of my clients.

That's right, EMF now supports Rich Ajax Platform (RAP) out of the box. This means that you can now generate a sample "single-sourced" application that can be run against either an RCP (Rich Client Platform) or a RAP runtime target. Details can be found on the New and Noteworthy page for the Helios release of EMF. Thanks again to Ed and Ben for their help in making this happen in time for M6!

On Architecture...

As you may have already gathered from Kim's blog (yes, we're both from the same province and home town, and no, the tidal bore is not a pig), I've recently been appointed to the Eclipse Architecture Council. It's an honor to be in the company of such great technical leaders, especially my Cloudsmith colleagues, two of whom (Thomas and Ed) are on the council as well.

I've actually been spending a lot of time looking at architecture (or lack thereof) of late, primarily within the Modeling project. As I've mentioned before, vision is one of the key contributors to a successful project, and a guiding architecture is an important part of such a vision. With the number of Modeling projects growing at an alarming rate (60+ and counting), it's going to be increasingly important to "bring order to the chaos", or risk the loss of potential consumers and contributors due to frustration, confusion, or both. Initiatives like Amalgam and the recently proposed Sphinx project certainly help, but there's a lot more that could be done.

Speaking of Sphinx, Stephan Eberle (one the proposed project leads) and I presented a talk at EclipseCon entitled "The Twenty Modeling Things", the slides for which can be viewed at Slideshare or via the EclipseCon session page. The basic idea of the presentation was to propose set of essential services that might one day form the basis for an integrated modeling workbench at Eclipse. Which "things" would you have included? Can you think of other services which ought to be on our list?

On Looking Up...

It's been a while since I last blogged, and much has happened in the meantime, including the completion of contracts with two different clients (more about those later), the M6 milestone of the Helios release, EclipseCon 2010, a vacation in the Dominican Republic, and, most recently, a case of Scarlet Fever (what a way to put a damper on a vacation!). It's funny, though, how much clearer you can see when your head is in the clouds.

As I've stated previously, I've been taking my time to carefully decide what my next venture would be. Well, I'm happy to say that, as of this week, I'm now working on a full-time basis with Cloudsmith Inc., as lead of product development. If you were at EclipseCon, you'll no doubt have heard of some of the great things Cloudsmith is doing. In case you haven't, you definitely will over the coming weeks.