Tuesday, May 18, 2010

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!

Monday, May 10, 2010

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!

Thursday, May 6, 2010

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!

Wednesday, May 5, 2010

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!