The Quest for Coolness

As you know from my previous blog, I've been thinking a great deal about "Really Cool Things."™ In fact, not only have I been thinking, I've taken action: I have embarked on a great quest. While wandering the vast desert of uncoolness, with nothing of interest as far as the eye could see, I thought I heard a voice as my eyes were drawn to a sparkle in the distant horizon. Could it be the enlightenment that I seek? The voice compelled me to go forth: "That which you seek is in Kiel," it whispered quietly. Meanwhile, my faithful companion found coolness in a stick.

Being somewhat impulsive, I immediately booked a flight to Germany. It leaves this coming Saturday and arrives on Sunday. From there my quest will continue; I think I'll start fasting. I know not what I'll find, never having been to Kiel, but I am confident that I'll find that which I seek: "Really Cool Things."™

All Cool Things

With Indigo behind me and Juno in the distant horizon, it's time to chart a new course. It was with great interest that I read Mile's inspirational and timely blog about Indolent Programming. I immediately recognized that I definitely prefer to work on Really Cool Things. Moreover, like a bolt of lightning, I had a startling revelation: providing service and support for a ten year old framework like EMF is totally, absolutely uncool. Granted it was definitely cool to create and popularize EMF and most certainly it's great for the uncounted clients relying heavily on EMF that it be well supported, but one salient fact stands stark: service and support is at the far end of the coolness spectrum. As a result of this awakening, I nurtured my inner Teflon Programmer, and embarked on a renewed quest for coolness. Who will support EMF in my stead, you might ask. Ms. Else of course!


She's the ultimate goat, to use Mile's enlightened terminology. She actually enjoys eating her own dog food. Not only that, if you throw her the occasional bone, she's simply beside herself. This will help free up much of my time. She'll be well qualified to hit some of my simple short cut keys. For example, the first answer to any newsgroup question will be, "Did you consult with your best friend, the debugger? She's able to answer questions far faster than me." Of course Else too has a backup, Ms. Ruby!


What will I do with my new found freedom? That's for me to know and for you to find out. The only thing I'll reveal is that at this moment, number one on my list is Eclipse Demo Camp Vancouver. See you there or be uncool; the choice is always yours.

So Much to Do, So Little Time

It's been ages since last I blogged. Where does all the time go? EclipseCon came and went in a whirlwind of activity. There wasn't nearly as much modeling content as in previous years and I know more than a few folks were frustrated that I rejected their talks. I didn't bother explaining that this year's selection process reduced me to tears; sometimes it's best to just clam up.


You'll probably be surprised to learn that I actually spent quite a bit of time in my evil secret lair doing cool technical work in recent months. EMF's RESTful persistence framework is heavily focused on stream-based I/O, but sometimes streams are just not what you really need. To enable greater flexibility, we've added two new interfaces to URIConverter: Loadable and Saveable. These make it easy to add a URIHandler that creates facades rather than real streams and via those facades persists a resource's contents in some arbitrary manner, i.e., in a database or some other type of structured repository. If you're interested in details about how to exploit these two new pillars, Byan Hunt blogged about MongoDB integration for EMF not so long ago.


As part of EMF's persistence flexibility enhancements, I vamped up the existing resource implementations as well. Of course they needed to detect the new stream facades in order to delegate appropriately, but more to the point, it's now also possible with a single resource implementation, i.e., XMIResourceImpl, to produce or consume binary using XMLResource.OPTION_BINARY, XML using XMIResource.OPTION_SUPPRESS_XMI, and of course XMI as usual. It's been a well hidden secret up to now, much like the new ODA support Kenn Hussey implemented!


The coolest new feature though is the improved ability to record a set of changes being made to a model and from that efficiently produce a change description that can be sent elsewhere and applied to replicate those changes. It's ironic that a feature so easy to describe is so deceptively difficult to implement. As part of its Change model EMF has long supported a ChangeRecorder that produces a ChangeDescription for this purpose. The problem is that it describes how to go from the current state back to the original state, i.e., it's a reverse delta. It's possible to call applyAndReverse to produce a forward delta, but that modifies the state of the model, i.e. , it's like undo. Of course it's also possible to call applyAndReverse as second time to redo the changes, but clearly that's not very efficient nor desirable when there's a user interface updating in response to all the changes. To address that problem, we've implemented copyAndReverse so that we can produce a serializeable forward delta without changing the state of the model itself. You might want to try it out and help stamp out any remaining bugs.


At the beginning of May I traveled to Germany for JAX and met up with a bunch of my friends for an Eclipse modeling day. The presentations and discussions were in German, so that was very tiring! Can you name all the Eclipse committers in this picture?


As part of the JAX trip to Europe, I spent some time in the Netherlands; I was born in Rijswijk and I took my mother long to visit with her family there while Frank and I stayed in Den Haag and then Amsterdam. I've never been to Amsterdam before and we happened to be there for Koninginnedag. That was quite amazing. No one can pack more boats on a small canal than the Dutch! The fact that their raft was being pushed under by the crowding boats didn't bother these guys one bit.


Not long after getting back from that, it was time for CodeGen 2011 in Cambridge where I did a keynote on the last day. That was a very interesting conference. I met lots of new people. I hope I'll be able to attend again next year. Mark Dalgarno, the conference organizer, did a great job. He even included a very memorably outing to experience punting on the Cambridge waterways.

Since then, like so many of you, I've been caught up in the final frenzied daze of Indigo. With that almost behind me, I am looking forward to a trip to Raleigh, North Carolina Monday for the Eclipse Board meeting. Speaking of which, the foundation is proposing some updates to the Eclipse Bylaws, so the committer representatives took the opportunity to propose a change to how we are elected. In particular, we looking to deliver on the one committer one vote principle. We're quite pleased about that and hope you are too.

The Universe is Unfair

Fairness is a highly subjective thing. It's not simply about everyone being treated equal, it's about everyone being treated in a way that's proportional to need, merit, or some combination of the two. The universe is objectively blind to need and merit. It rains fortune and misfortune on the guilty and the innocent with equal abandon. Given that the universe is unfair, we must intervene to rectify the situation and be prepared that when we do, it will be, as Dave points out, contentious.


So it is with divvying out the Friends of Eclipse funds. Scott suggests we give up. Just kidding; I'm distorting his words by taking them out of context. What's life without a bit of humor? He actually suggests we give up centralized control. Fortunately he doesn't mean we should have a vote each and every time. We all know how contentious voting can be and how easily one can stack the vote with all your best friends. It's more likely to resemble a popularity contest than anything else.


Concretely, in 339239, Scott suggests that the individuals donating the money should make the decision. I'm not completely sure what this would entail. I think the suggestion is that the donor delegates the spending decision to a specific project's leadership, sort of like ear marking it, perhaps via a huge drop-down list of all projects. That certainly sounds very fair, at least to the donor.


Let's consider though just for a moment if donor earmarking is likely to be fair in the grand scheme of things. I hope the Aardvark project, being early in the list of choices, doesn't get most of the donations! I hope projects with poor documentation, builds, and testing get some money to help fix that. I hope projects that are used in the many other projects, but aren't apparent in the user interface, get lots of donations. In fact, I hope it's not just a few sexy projects that get the lion's share of the money. Simply put, I hope the donors will be fair. I doubt it though. I fear it will just be a case of the rich getting richer. Personally, I'd rather have people I trust to do what's fair making the decisions.

To be Fair and Balanced, That is the Question

As you may or may not be aware, your committer representatives are responsible for the allocation of the Friends of Eclipse fund. There's not a lot of money and we'd like to use it in a way that promotes our community. A few people have proposed ideas. Some were accepted and some were not. We'd like to think our decision making process was fair and balanced, but that's been called into question, particularly with regard to a request for release engineering support for ECF. As a group, all the people currently running to be a committer representative agreed that using the community's limited funding to scratch the admittedly nasty itch of one specific project isn't appropriate.


To me, that seems fair and balanced, but apparently some are inclined to see it differently. Simply put, we are doing damage to small projects like ECF by saying no, we have wasted the valuable time they spent asking for money, and we generally don't represent the interests of the community. The list of things we're doing poorly is long and we're clearly bad people. It's ironic to me how often those most skilled at dishing out critique---calling Ekke an ignorant hack being another good example---are the very same ones so easily offended by another's poor choice of words. I need to keep an open mind though, so if others feel we've misjudged in our decisions, please let us know your thoughts.

Procrastination

Never put off until tomorrow what you can forget about forever. After all, some problems will just go away on their own if you ignore them long enough, right?


I've been so busy these past months that a great many things have slipped through the cracks. I'm beginning to think there are more cracks than solid ground. Last I blogged I'd just traveled to Zurich for Eclipse Enterprise Modeling Day as well as to Ludwigsburg for Eclipse Summit Europe and I was living in Maple Ridge. Three months later, I'm planning a trip to Zurich for a Modeling Workshop---don't procrastinate, register immediately or miss your opportunity---as well as a trip to Santa Clara for yet another fun-filled, action-packed EclipseCon and I'm living in amazing downtown Vancouver; the Tasktop office just a five minute walk away. What happened to the house plans? A word to the wise: if you think we software engineers have trouble staying on schedule and within budget, the North American construction industry makes our industry look like a well-oiled machine. I'd rather step on a stone fish than try to design and build my own house again; it would a much quicker and far less painful death.


Don't forget, it's election time again for the Committer Representatives of the Eclipse Board of Directors. I thought fierce mudslinging might ensue while I was off gallivanting around the far east, but apparently it's turning out to be another tame campaign. While all the candidates are very good, and obviously very nice, I'm clearly by far the best because I have the prettiest underwater photographs.


Okay, that's not terribly relevant. But I do have a proven track record when it comes to braving shark-infested waters.


That's an essential skill to be sure! If you plan to vote, you have until March 11th to procrastinate.

Modeling in Europe

I've been in Europe since October 27th. The trip started with a visit to Zurich to attend the Eclipse Enterprise Modeling Day hosted by UBS. It was very well organized and a great success! This was my first visit to Zurich and I was fortunate to have time for sightseeing with Frank before heading off to Ludwigsburg on October 31st. Zurich is a fantastically beautiful city!

The day before Eclipse Summit Europe, was the face-to-face Eclipse Board of Directors meeting, so the week was off to an interesting start. I was still organizing the content for the Modeling Symposium the following day. Agile preparation I like to call it though some might use the word procrastination.

I think the symposium was a great success. It was a chance for a large number of presenters to demonstrate their favorite technology in action and gave the attendees a diverse overview of many topics they might not learn about otherwise. Each presenter was kind enough to write a brief abstract, which I've included in this blog.

Semi-automated Model Transformations with Mitra and GEF3D

In OMG's "MDA Guide," model transformations are described to "be done manually, with computer assistance, or automatically." Research generally focuses on automated transformations. However, fully automated transformations can not always be applied. In this mini talk, we have a closer look at computer-assisted transformations (CATs), a language for programming them (Mitra) and, as CATs require user interactions, a 3D user interface based on GEF3D. As a result, model elements can simply be dragged from one model to another model, and when dropped these elements are automatically transformed. We demonstrate CATs by means of Jacobson's robustness analysis (known from the Rational Unified Process) and a tool for adding markers to arbitrary Ecore-based models.


Jens von Pilgrim mentioned that modeling without diagrams is like Tour de France without mountains: sure you can do it, and it's maybe even easier, but it takes out all the fun. He shows how he can drag from one diagram type to another, i.e., to transform a use case diagram into a class diagram.

Advanced Features for Migrating Models with COPE

When an Ecore model evolves, existing instances may need to be migrated. To automate the migration of these instances, COPE records the instance migration together with the Ecore model evolution in an explicit history model. The history model specifies the sequence of coupled operations that have been performed. A coupled operation encapsulates both Ecore model evolution and instance migration. Instance migration can be further automated by reusing recurring coupled operations. In this demo, we show the more advanced features of COPE to inspect and refactor the history model as well as to reverse engineer it from two versions of an Ecore model.


Markus Herrmannsdörfer demonstrated how he can use the information for transforming one Ecore model to another into a script that can transform an instance of the first model into an instance of a second model.

Modeling Eclipse Plug-in Artifacts

An Eclipse plug-in is a complex component based on heterogeneous artifacts, e.g., source code, manifest, XML files, properties files, and so on. We will demonstrate how EMF can be used to produce a homogeneous representation of these artifacts and provide a comprehensive model of an existing plug-in. We will illustrate how this model can be used to check development rules or refactor plug-ins.


It was cool to see Frédéric Madiot demonstrate how every last detailed aspect of an Eclipse plug-in is represented as Ecore-based model! He then proceeded to show all the things one can do with this information, e.g., implementing additional quality checks such as the need (for the Eclipse release process) for there to be an about.html file, as well transforming a plug-in from being Eclipse 3.x-based to e4-based.

Only One Click to an EMF Application

We will demonstrate how to develop an example application with the EMF Client Platform and EMFStore. A developer only needs to define an Ecore model for the application´s entities. Based on the EMF Client Platform this already defines a basic User Interface for editing. EMFStore allows storing and distributing the instances of the model. Everything just with the click of a button, that is launching an Eclipse instance with the model plug-in.


Jonas Helming and Maximilian Koegel did three quick demos. The first showed how one can rapidly prototype model designs and test their capabilities with a high-quality editor, i.e., one with forms for editing properties. The next showed the CVS-like ability of their model repository. And finally they showed how they can integrate their repository-approach with SVN.

The CDO Model Repository – Being Connected and Unconnected

In addition to the traditional connected mode, the Helios version of CDO comes with a sophisticated offline mode that has been inspired by distributed versioning systems like Git and is almost transparent for end user applications. If you feel uncomfortable with replicating the entire history of all branches of your master repository you may be interested in this demo. We’ll present the brand new offline workspace facility, which provides you with a more CVS/SVN-like workflow: checkout, update, commit. In combination with our new EFS implementation you can seamlessly integrate your CDO-managed object graphs with any existing Eclipse technology that is based on IFiles, while still being able to access the underlying object graphs.


One of the coolest things Eike Stepper shows is the integration with the Eclipse File System where the repository contents are surfaced as IResources.

Papyrus in Action

We will introduce the Papyrus team during the session, and we will then present the MDT Papyrus project itself. The talk will focus on the UML2 abilities of the tool, full compliance towards UML2 specification, and Domain Specific Modeling Language development facilities using UML2 profiles. We will also demonstrate the various possibilities of tool customization and finally we will present the road map for the next releases.


Remi Schnekenburger and Patrick Tessier showed some of the Papyrus capabilities, such as customizing the diagrams based on stereotype application.

Acceleo on e4

During this presentation, you will see a prototype of the modeling project Acceleo on the e4 platform. That presentation will also give you the opportunity to hear the feedback of this experimental transition to e4 with its advantages and drawbacks.


Stephane Begaudeau showed some of Acceleo's nice integration features, such as its own perspective with views that show things like all the objects accessed when generating a particular artifact; an important traceability feature.

Reconciling Multiple Representations for BPMN 2.0.

The new BPMN 2.0 standard provides a good basis for interoperability between Process Modeling tools and engines from different vendors. An EMF metamodel allows one to read and write standard compliant files and offers a good API for all kinds of tools. Such a metamodel was committed to Eclipse MDT project. However it was not as simple to create as you might have thought: Unfortunately OMG defines both, a CMOF metamodel and an XML Schema, resulting in two official file formats that such an implementation must consider. Fortunately EMF provides a solution for almost everything. I’ll demo how you can merge the two sources, the EMF tricks that were used, and how finally the BPMN implementation works.


Reiner Hille-Doering talked about the incompatibilities between CMOF, with multi-inheritance and typed references verses XML Schema which single inheritance and untyped reference. The difference between these two ways of defining the model needs to be reconciled to produce a single model capable of reading and writing the exchange format implied by each definition. Because it's a large model, he defined an automated way of merging the two to produce a single result annotated with extended metadata.

Dynamic Domain Models for JUnit using EMF, redView and Xtext

Implementing unit tests for business applications means running the same test classes again and again with different inputs and expected outputs. This session should demo, how EMF, redView and Xtext can be used to create reusable test instances which can be configured by dynamic domain models.

• Xtext defines the test case specific domain model
• redView renders and binds a matching ui at runtime
• EMF stores the information in a key-value-map

Florian Pirchner showed how they can use model changes to dynamically update JDT's AST to reflect those changes.

Bonita Open Solution: Leveraging Modeling Power for Customization

We will see how the BonitaSoft team leveraged power of Modeling to turn a simple RCP-based modeler into a highly customized and user-friendly application. I will talk about some GMF-based customization in Bonita Open Solution Studio, and show how this customization is done with repeatable code generation to ensure agility and maintainability.

Aurelien Pupier showed two of their GMF-based editors. Their editors have nice contextual palette that make creating models very easy. They've done a good job making a stylish application.

Typesystems for Xtext Languages

Ever wondered about how to efficiently write the constraints for checking the correctness of non-trivial typing rules in Xtext languages? This short talk introduces the Xtext Typesystem framework which supports the declarative definition of a wide range of typing rules for Xtext languages. I will show a few slides to explain the background and how it works, and then I'll demo how to integrate a typesystem with an actual Xtext language editor.


Markus Völter showed a grammar for a simple expression language and proceeded to demonstrate how a simple type system can be constructed from that. E.g., define the types of the literals (i.e., of the leaf expressions) and then the rules for deriving the type of composite expressions.

Modeling Meets JDT: Leverage Java Types in Your Models

A tight integration with the Java Types and the Java Development Tools (JDT) is a sweet spot especially, but not only, for textual modeling. That's why we developed a lightweight EMF representation of the Java VM types, their operations, and fields as part of the Xtext framework. In this short demo I'll show how we used the abstractions of EMF and the power of dependency injection by means of Google Guice to allow a seamless integration of modeling components with Java VM types. Especially interesting is the dedicated EMF resource implementation that allows clients to work transparently with the Java reflection layer or the available information from a JDT based Eclipse Java project. Furthermore, I'll give a short demo on how the Modeling Workflow Engine (MWE) leverages this feature to provide a highly extensible configuration language including advanced tool support for users.


Sebastian Zarnekow started with a simple DSL to show how, with the use of the JVM type model, it's possible to refer to Java classes. It seamless derives its information either from JDT or via Java reflection, depending on your environment context. Very cool and powerful stuff.

Xdoc - When Writing Documentation is Fun

Xtext comes with extensive documentation published as Eclipse Help, as HTML on our website as well as PDF for printing and offline reading. The documentation is written in Xdoc, a markup language tailored for the purpose of writing documentation for Eclipse projects. This is a short demo of Xdoc and its editing features.


One of the things Sven Efftinge requested is for folks to post information on 328477 about their use of Xtext. He then proceeded to demonstrate the capabilities of Xdoc, a DSL similar to wiki and TeX for writing documentation, with a simple example document.

Diagram views of Xtext Grammars (5 minutes)

The Xtext Syntax View visualizes the syntax of your Xtext language in a railroad diagram. It helps to analyze, debug, and document your Xtext based languages.


Jan Köhnlein's very quick demonstration of his railroad diagram pet project was very cool, so much so that I neglected to get his picture! So I took his snapshot during the beer and pretzel reception right after.

Eclipse Modeling Platform

The Eclipse Modeling Platform (EMP) is an industrial quality integrated software platform to enable complete chains of model-centric tools in organizations focused on model driven development. The requirements for EMP are being set by some of the largest companies using model driven development. EMP will be developed as an Eclipse Industry Working Group supporting a collection of open source projects and encouraging a commercial ecosystem of value-added tools and services. The platform will be based on existing Eclipse modeling technologies but focus on better integration, quality, scalability and usability for modeling professionals.

This talk will give an insight into what is being done in the Modeling Platform Industry Working Group (MPIWG) and who is collaborating in this forum. It will also reflect the relation of the EMP to the existing Eclipse modeling projects and explain why these are promising days for getting this started.

Stephan Eberle gave much the same talk as he did a the Eclipse Modeling Day in Zurich last week.

The rest of the conference, as expected, was fantastic as well. I didn't get to attend all the talks I would have liked to attend, but face-to-face time is one of the primary reasons for traveling to these types of events, so it often takes priority. As with all good things, it came to an end all too quickly.

Friday November 5th, the day after the conference, was a face-to-face meeting of the Modeling Platform Industrial Working Group. It was held at the conference center. Stephan Eberle and Martin Mandischer have been doing a fantastic job gathering requirements, analyzing the gaps that need attention, and outlining a plan for making it happen. Things are progressing well.

No trip to Germany is complete without a stop in Berlin, so that's where I headed Friday night to meet up with Frank, who had been there all that week. We even had a chance to visit Dresden on Sunday. Neither pictures nor words can do that city justice!


Today is our last full day in Germany before heading home to Vancouver tomorrow. It's been a great trip and I'm sure we'll be back soon.