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!

3 comments:

David Carver said...

I've always viewed the core of emf as a runtime platform that doesn't have any eclipse dependencies. I've used it this way in the past, and think that is still it's biggest strength, but one that is under promoted.

Miles Parker said...

Me too. Fundamentally it supports a representation with much richer semantics than say XML but not so abstract and generic that it loses touch with real world software development.

So I've never seen the representation as really just about the code generation but about all of the infrastructure that this common semantic structure supports. That's always been both theoretically and practically true on the model level, and its really cool to see it become true on the edit level as well.

As a plug, the AMF platform was built from the start to support multiple model level generation. I'm not suggesting that AMF itself is appropriate for more general usages but it would be neat to see more examples of EMF-based generation for specialized targets, such as.. oh yeah, I better not say any more cause I don't want anyone to take out a patent on it.

I gotta ask, have you thought about having a "genmodel genmodel"? Otherwise there is really no way to have a build without tweaking a model artifact. To me, the current genmodel looks more like an editmodel.

Kenn Hussey said...

Yes, the real value is in the EMF "runtime"; the code generator just gets you up and running with it more quickly and, hopefully, demonstrates some best practice patterns in the process.

I actually proposed a generator model generator a few years ago when we restructured the code generator to be more extensible. At the time, it was seen as more effort than it was worth, but now, as the number of options (and number of runtime platforms) continues to grow, that may not be true anymore...