Sunday, 23 December 2007

Eclipse and the OMG: Two Great Things that Go Great Together

The Object Management Group is planning a workshop to coincide with EclipseCon. The call for submissions is out. More details are available in the announcement Kenn posted to the modeling newsgroup.

The OMG has a long history as a place for developing modeling-related specifications and Eclipse has become the place where the de facto reference implementations reside. So I wrote a little derivative poem to commemorate this grand convergence of specifications and their implementations.


Two roads converged in a yellow wood,
And sorry we had to travel both
And be two travelers, long we stood
And looked down each as far as we could
To where they met in the undergrowth.

Then we each took our path, as just as fair,
And having perhaps the better claim,
Because it seemed greener for want of wear;
Though as for that the passing there
Had worn them really about the same.

And both that morning equally lay
In leaves few steps had trodden black.
Oh, we kept the other for a different day!
Yet knowing that our way seemed the better way,
We doubted we should ever come back.

We shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads converged in a wood, and we--
We each took the one less traveled by,
And that has brought us to a common point.

Friday, 21 December 2007

Can a Tiger Change its Stripes?

I recently set up a community tank with a diverse collection of plants and fish.


To manage the community well, you have to choose your fish carefully to ensure they will fit in with the rest of the community. This little tiger striped loach fits in rather well.


With the recent Tigerstripe proposal the modeling PMC was faced with a similar type of choice. The proposal was originally written as a general purpose model driven development technology that would help round out some of the gaps in the modeling project's technology. Eric Dillon gave Rich and I an overview and a demo of the technology. We immediately expressed concerns about a number of detailed issues.

We had to wonder, is Tigerstripe an industry vertical model driven development technology used to define Telcon standards or is it a general purpose model driven development technology based on existing standards? As I said, initially Tigerstripe was proposed as a general purpose model driven development technology but upon closer scrutiny, the proposal was changed to be an industry vertical model driven development technology, though obviously the actual technology itself didn't change, only the way it is presented. This still leaves doubt as to the true intended nature of this technology and how it integrates with the established Eclipse community.

If Tigerstripe is really intended as a technology for defining industry vertical standards it should be strongly grounded on existing standards, e.g., profiled UML would be one reasonable approach, yet the relationship to UML is somewhat in doubt. The proposal seems to characterize it as a subset of UML, but I'm not sure what to call the model, since Tigerstripe seems to be a brand that denotes many things. In fact, I'm not even sure if there is an Ecore/EMOF-based metamodel for it.

An alternative to profiled UML would be the definition and development of a domain specific language, but that does not appear to be the proposed approach. Defining an EMOF/Ecore model for a domain specific language would make the technology well integrated with the existing modeling project infrastructure and would make it much more clear the nature of the target domain.


We were also concerned about rebranding a commercial brand with Eclipse's stamp of approval. It seems to me that allowing a proposal to proceed before resolving the issue of a commercial brand is problematic. I suppose it will be argued that these folks intend to make it an Eclipse brand in the future, but those discussions did not take place in the open so I can't comment on how they were resolved. In any case, the approach of publishing a proposal using what is currently a commercial brand is something that the community does question and the foundation perhaps should be seen to be acting strongly to protect the Eclipse brand from this type of confusion. Note that I didn't say they aren't, I'm saying there's a perception problem.

In the end, all this has served to create confusion in the community. The community really doesn't know what it will get. It seems we won't be seeing profiled UML nor a domain specific language. We're not sure we'll even get an EMOF/Ecore-based model. So we don't know if any existing modeling technologies, such as JET, XPand, ATL, QVT, OCL, transaction, validation, and so on will be applicable. The lack of clear answers to questions raised on the newsgroup leaves us a bit doubtful that good intentions will prevail, though I don't question the good intentions themselves since Eric is quite clearly a very nice person with whom I'd love to work, but development costs have a way to interfering with good intentions.


The creation review slides talk about Tigerstripe being a framework for "commercial Cisco extensions" yet it says nothing about the nature of the extensibility mechanisms. The modeling community really wants to understand how this technology will fit in and to date, we've only seen the proposal shift itself shift out from under us; that doesn't inspire confidence. The modeling project is already providing a framework for model driven engineering, but the slides claim the same without qualification as to the scope. They're vague about what kind of integration with the modeling project Tigerstripe will provide. Certainly there is no need for another UML model nor for class and instance diagrams, because those things are already supported.

While Eclipse doesn't have rules to prevent competition, nor should it, Eclipse is founded on principles of cooperation to share costs and to unify communities, so this proposal goes a little against the general grain. Though I suppose it's no longer claiming to provide a competitive UML model, but rather a subset because UML itself is too complex. To rant on a bit more, it's not clear what a headless build environment is; I imagine Eclipse already has that. Nor is it clear what a plugin engine is; I wonder how it relates to the model workflow engine. If the model is UML2 then it's unclear why there is a need for UML import and export. It is simply not clear that there is a real plan in place to reuse UML2 and given the lack of answers to specific questions (i.e., if Tigerstripe didn't use UML2 two years ago why will it start using it now?) there is room for doubt. It's also not clear what an XML export plugin is all about; EMF already supports XML serialization for any model, so the relationship to that is unclear. And finally, it would have been good if someone had explained that the V2.3 goal in the proposal is not possible with Eclipse's incubation and version numbering rules.

I feel like I'm being a total downer on this subject and that's made me repeatedly question my own motivations. Am I just being defensive or even worse protectionist? Am I failing to be open minded? Goodness knows that wouldn't be the first time. Is it reasonable to vote -1 on a creation review and not even give folks a chance to prove themselves? Certainly there is value in an industry vertical modeling technology, but there are an awful lot of questions and I think the situation has been handled poorly with a little too much emphasis on driving forward without much time proper reflection. Sorry for being such a downer...

It's probably not politically correct to question whether Cisco should consider coughing up Strategic Developer costs to help pay for the infrastructure it will use and for the IP resource it will consume. But I think such meta questions also need to be asked. Much smaller organizations have shown more financial commitment toward Eclipse than has Cisco to date.

So I'm trying to keep an open mind and to be transparent with the hope that my heart is in the right place.


As such, I will appreciate any comments folks might have in terms of advice on how this should be handled. I'm just not sure and I'm second guessing myself so I will try to accept criticism graciously. Fire away!

Please Reinstate The Top Contributor Award

Nominations for this year's Eclipse Community Awards are open but unfortunately the Top Contributor award has gone absent without leave. I sent Ruby out searching for it:


After some effort, she and Amber rooted out 213601. Apparently there was some confusion about the distinction between Top Committer verses Top Contributor, but that just left Amber perplexed:


She figured that both these terms are quite clearly defined and that the definitions are well understood by the community. Given that a picture is worth a thousand words, here is how Top Committer is defined pictorially for the illiterate:


I'll leave it as an exercise for the reader to imagine what the Top Contributor award would look like pictorially based on extrapolating from the definition of Top Committer which "Recognizes an Eclipse committer who best exemplifies support for the community through newsgroups, Bugzilla, white papers, conference presentations, blogs and other forums." It seems obvious that Top Contributor "Recognizes an Eclipse contributor who best exemplifies support for the community through newsgroups, Bugzilla, white papers, conference presentations, blogs and other forums."

I suspect that the confusing part in previous years was that committers could not vote on the committer award and that the community at large could not vote on the contributor award (if my recollection is accurate). That seemed odd to me because with regard to the platform project, I am a community member, not a committer, and if I provide patches and a test case, then I'm a contributor to the platform project. An excellent example of this is dual aspect is Tom Schindl who is a committer on the platform UI, but as far as I'm concerned, from EMF perspective he is a top contributor because of 209434, 209435, and 211340. So I think that both committers and contributors ought to be able to vote for both awards and that the biggest point of confusion is likely the dual role folks play within the community. But that's just another aspect we ought to encourage. Let's not leave contributors out in the cold.


I don't think the distinction between committer and contributor is the least bit confusing and certainly doesn't require two paragraphs to explain well; just read the IP policy for clear definitions of these terms. Once the terms are well understood, the reason for an award for each seems self evident. Nick made an effort to provide the requisite two paragraphs to get Bjorn's +1, and while Ian thought the distinction of "committers are paid but contributors are not" was useful, I'm with Remy on this one: a giant -1 on the notion that renumeration or lack there of is a useful distinguishing characteristic. There are an awful lot of people committing or contributing valuable results simply based on their passion for Eclipse without that work directly earning them a single extra penny. People like Martin Taal, Eike Stepper, Sandro Boehme, Bernd Kolb and others (whom I won't mention because they've not contributed their photos on the EMFT contributors page despite reminders; expect to be nagged further) are perfect examples of committers who aren't being paid by anyone for their commits.

Given the high value we committers place on the community at large and especially on the contributing subset within that community, we most certainly ought to have an award to recognize those who best exemplify this valuable trait.

Please don't take our sunshine away!

Thursday, 6 December 2007

No Good Deed Goes Unpunished

I'm a firm believer in the old adage that "No good deed goes unpunished." Why is that you might ask? Well, it's because a good deed is clearly done with good intent and of course we all know that the road to hell is paved with good intentions. So it follows that a good deed is often the first step on the way to hell. Of course most roads in the Eclipse community are paved with good intentions, so I certainly don't think they're all leading straight to hell, but one misstep and you could be well on your way. Goodness knows there are enough people watching for a misstep. In any case, I'd like to think that if hell froze over, it would look like this:


One always hopes that others will recognize good intentions for what they are and that when the actual results of well intended efforts do not match precisely the intent, that the intent is not forgotten.

I've often been told that I color my language with too much emotion and I'm sure that's true. It's a common failing of those with passion to misdirect that passion when sensibilities are violated. One might call that irresponsible, but that's using emotional language. It's always a good idea to focus on criticizing the ideas rather than criticizing people directly. Its also important to keep in mind that none of us really like personal criticism, or any kind of criticism for that matter. As such, even constructive criticism is not always well received despite the good intentions of those dishing it out. This basic failing in human nature makes it extremely difficult to influence change without giving others cause for taking offense.

I write this blog to help remind myself and others to think carefully when dishing out criticism. It's best to state all criticism in the form of a positive suggestions for improvements. Always make it clear your intentions are good. You're still likely to end up on the road to hell, but ask yourself this: What are the roads that lead away from hell paved with?


I'll climb down off of my high horse now---or is that my soap box? it's so hard to tell--- before someone knocks me off....

Tuesday, 4 December 2007

Winter's Icy Grip

Sunday night we had freezing rain north of Toronto. We never had such things in Vancouver where I grew up, just lots of normal rain. Predictions of freezing rain always make me worried about the garden, but there was little damage and much beauty. Diversity of weather certainly has its points of interest. This shot of a berry locked away in ice was my favorite for the day.


Monday was also the day that the Friends of Eclipse program was launched. As a committer representative on the board, I received advanced notice on Sunday. This is a program the committer representatives asked the foundation to look into setting up, so naturally I was thrilled with Ian's results and at the opportunity to be one of the first to demonstrate my friendship with my wallet, not just with my words. I even outbid Mike, but then the stakes quickly became to high for me! (I must say, Jeff is such a competitive guy!) Have a look at how quickly the donor list is growing! There's even a kind remark about modeling. How nice is that?

I'm proud to display a Friends of Eclipse logo on my blog home page. Thanks to Nathan, it's not just a one size fits all logo either, but rather is available in small, medium, and large. I suppose pride is a sin, so I should say I'm honored to display it. Eclipse has been my friend for a long time, so it's nice to know that now I'm Eclipse's friend...

Today the sun came out again. The combination of sun and ice is quite a thing!


I love a sunny day with fresh snow. You can see from all the ice on my blue spruce offset so nicely by the blue sky why I might worry about damage. It's a lot of extra weight to bear!


Even the girls think the snow is kind of cool, but I have to clear a bit of the backyard for them since they tend to disappear in a foot of snow.


I've not been busy just taking pictures either! I've been working on something that's kind of cool and also relatively simple. Have you ever heard of a substitution group? I see I've piqued your curiosity. (Just ask her where the ducky is and she'll give you this same look!)



A substitution group is an XML Schema thing and is what I call syntactic sugar because it's primary purpose is to make your XML serialization look pretty by allowing the instance to avoid the use of xsi:type. Though goodness knows it's beyond me why anyone cares that something as ugly as XML should be made slightly less ugly when it's barely human readable in the first place, but hey, there are an awful lot of people who are quite obsessed with the prettiness of their XML.

So here's the basic idea. Suppose I defined a type Resource with two subtypes, Folder and File, where a Folder has a list of members of type Resource. To round it out, we might define a FileSystem as having a list of folders. We could define that in XML Schema like this:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:resource="http://www.example.com/resource"
targetNamespace="http://www.example.com/resource">

<xsd:element name="fileSystem"
type="resource:FileSystem"/>
<xsd:complexType name="FileSystem">
<xsd:sequence>
<xsd:element name="folder"
ecore:name="folders" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:element name="member"
ecore:name="members" type="resource:Resource"/>
<xsd:complexType name="Resource" abstract="true">
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>

<xsd:complexType name="Folder">
<xsd:complexContent>
<xsd:extension base="resource:Resource">
<xsd:sequence>
<xsd:element ref="resource:member"
ecore:name="members" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="File">
<xsd:complexContent>
<xsd:extension base="resource:Resource">
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

</xsd:schema>
Generating the EMF code for the above, we could use the generated API to create an instance like this:
Resource resource =
resourceSet.createResource
(URI.createURI("http:///My.resource"));
DocumentRoot documentRoot =
ResourceFactory.eINSTANCE.createDocumentRoot();
FileSystem fileSystem =
ResourceFactory.eINSTANCE.createFileSystem();
documentRoot.setFileSystem(fileSystem);
Folder folder1 =
ResourceFactory.eINSTANCE.createFolder();
fileSystem.getFolders().add(folder1);
folder1.setName("folder1");
File file1 = ResourceFactory.eINSTANCE.createFile();
file1.setName("file1");
folder1.getMembers().add(file1);
resource.getContents().add(documentRoot);
resource.save(System.out, null);
ByteArrayOutputStream out = new ByteArrayOutputStream();
resource.save(out, null);
Resource resource2 =
resourceSet.createResource
(URI.createURI("http:///My2.resource"));
resource2.load
(new ByteArrayInputStream(out.toByteArray()), null);
DocumentRoot loadedDocumentRoot =
(DocumentRoot)resource2.getContents().get(0);
The resulting serialization looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<resource:fileSystem
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:resource="http://www.example.com/resource">
<folder xsi:type="resource:Folder" name="folder1">
<resource:member xsi:type="resource:File" name="file1"/>
</folder>
</resource:fileSystem>
To our horror, it's full of xsi:types! Clearly it's metadata and it offends our sensibilities to see such metadata mixed in our data. Of course the element and attribute names are metadata too, and xsi:type is something that any conforming XML processor must handle, but let's not cloud an emotional issue with facts.

You might wonder why these xsi:types are even needed? If you think about it, when you seen an element named member, you won't know if it's a folder or a file, so you won't know what elements and attributes to expect in addition to those you would expect for a Resource. For EMF such information is important too because we need to create the right type of object.

To deal with this type of issue, XML Schema defines the notion of a substitution group. Here's the idea. We define new elements named folder and file and declare that they are in the substitution group for the member element.
<xsd:element name="folder"
substitutionGroup="resource:member"
type="resource:Folder"/>
<xsd:element name="file"
substitutionGroup="resource:member"
type="resource:File"/>
Now, where ever a member element may appear, a folder or file element can be substituted. And of course, once we see that element, we'll know the type of that element and hence won't need an xsi:type. If we are feeling particularly clever, we might even declare the member element abstract because Resource is abstract and hence we'd never expect to see a member element.
<xsd:element name="member"
ecore:name="members"
type="resource:Resource"
abstract="true"/>
So now we can go back, generate our API again, and try to rerun our previous example, which ends up failing with the incredibly helpful runtime exception that says
Invalid entry feature 'Folder.members'
Naturally we scurry off to the EMF newsgroup where it's explained to us that the members feature is read only because the members element is abstract. We must specify a "document root" feature in some horrible feature map that we didn't notice was generated in the Folder interface and that we don't know how to use.
FeatureMap getMembersGroup();
Finally we come to realize, based on the helpful advice, that we must change our example like this:
// folder1.getMembers().add(file1);
folder1.getMembersGroup().add
(ResourcePackage.Literals.DOCUMENT_ROOT__FILE, file1);
Woo hoo. Finally we have it producing what we want.
<?xml version="1.0" encoding="UTF-8"?>
<resource:fileSystem
xmlns:resource="http://www.example.com/resource">
<resource:folder name="folder1">
<resource:file name="file1"/>
</resource:folder>
</resource:fileSystem>
But it's kind of a bitter sweet victory because clearly our syntactic sugar has turned into semantic rat poison. So many folks won't quite be satisfied and some I know have even gone through great lengths to suppress the rat poison from the API and to write clever code that figures if you add a File to the getMembers() list, you really must mean you want to use the document root's file feature since that's the only choice available. It's clear that this kind of cleverness could be handled by the serializer itself, so I've added support for XMLResource.OPTION_ELEMENT_HANDLER along with an XML Schema annotation to eliminate the semantic rat poison:
<xsd:schema
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
ecore:ignoreSubstitutionGroups="true"
If we reload the schema and regenerate the API, it goes back to like we had it before. Then we can change the code to how we had it and we can add the new option to the regenerated resource factory's createResource method:
result.getDefaultSaveOptions().put
(XMLResource.OPTION_ELEMENT_HANDLER,
new ElementHandlerImpl(false));
The result is that we get the same sugary sweet serialization without the rotten decay in the API.

While I was at it, I thought I might as well look at eliminating the need to use a document root, since that rubs some people the wrong way. Often folks don't understand why it even exists and it's effectively just another example of semantic rat poison. As modelers, we're quite used to the concept of having an object that is an instance of some type, and that corresponds directly to having an instance of some type in XML schema. But the root of an XML document doesn't specify a type name, it specifies an element name. Hence a DocumentRoot is like an invisible root object that has features to contain the real root object; the name of that containing feature determines the root element's name. So clearly if we can deduce a substitution group element during serialization based on the type of object being serialized, we can also deduce a correct root element name in a very similar way. The new element handler option supports that as well, so all that remains is to be able to suppress the document root during load and then we can pretend that document roots don't exist at all.

The new option XMLResource.OPTION_SUPPRESS_DOCUMENT_ROOT can be used to suppress loading of a document root. We just need to add it to your generate createResource method.
result.getDefaultLoadOptions().put
(XMLResource.OPTION_SUPPRESS_DOCUMENT_ROOT,
Boolean.TRUE);
Then we can rewrite our example to omit the document root.
Resource resource =
resourceSet.createResource
(URI.createURI("http:///My.resource"));
FileSystem fileSystem =
ResourceFactory.eINSTANCE.createFileSystem();
Folder folder1 = ResourceFactory.eINSTANCE.createFolder();
fileSystem.getFolders().add(folder1);
folder1.setName("folder1");
File file1 = ResourceFactory.eINSTANCE.createFile();
file1.setName("file1");
folder1.getMembers().add(file1);
resource.getContents().add(fileSystem);
resource.save(System.out, null);
ByteArrayOutputStream out = new ByteArrayOutputStream();
resource.save(out, null);
Resource resource2 =
resourceSet.createResource
(URI.createURI("http:///My2.resource"));
resource2.load
(new ByteArrayInputStream(out.toByteArray()), null);
FileSystem loadedFileSystem =
(FileSystem)resource2.getContents().get(0);
It's thing of beauty. Sugar without decay.

Here's a final image to capture your imagination. It's like a Rorschach inkblot test. What do you see in this picture?

Tuesday, 13 November 2007

Reflections on Power

I wanted to share with folks a few of my personal reflections on the nature of power. To start with, it's important to understand what specifically I mean by the word power. Of course Wikipedia is our best friend when it comes questions like that. If you look there to help understand what power is, you'll see that it says "Power has many meanings, most of which imply (a capacity for) control or force." At the time of this writing, there was also a very powerful message at the top of the page, "You can help Wikimedia change the world!" Indeed! It is on this sociological aspect of power that I'd like to focus because it has interesting implications for open communities as well for the individuals in them. Of course power is definitely about control and force; even in the sociological sense, power is both something that constrains (i.e., controls the results of an action) as well as something that enables (i.e., forces the results of an action in particular direction). In the exercise of power there is a balance between coercion and influence, with the ultimate purpose being to bring about change (or perhaps to prevent it).

A particularly powerful analogy for me is to think of power as flame that is fed by the force of living things. As introspective conscious entities, we're in a unique position to contemplate power in this pure form. I visualize power as a flame into which I feed my thoughts and from that a manifest entity with a life of its own takes shape. That entity can and does exist independently of me, but I feed it and without anyone like me, it would vanish in the blink of an eye, just as would a flame without its fuel, the oxygen to consume that fuel, and the conditions in which to renew and drive the process. And just as a flame has power over its environment, so too, power has power over us. It's an extremely important principle to keep in mind that the extent to which one tries to coerce power, it will take control.


So I see power as a flame that should be held forth with a gently cupped hand both as something to carefully nurture and protect and as something with a life of its own to be kept separate and at a distance lest it consume more than one might intend. It's is not something to be clutched with a greedy fist and held close, for surely it will consume the holder and then it will escape entirely or cease to exist. Like the old saying "If you love something, set it free; if it comes back it's yours; if it doesn't it never was." When you share your power freely with other like minded people, the power grows in unexpected ways. Beware of those who will clutch and grab for power, and be most wary of that person being yourself. Greed is a basic human failing, don't ever assume you are above it. As the saying goes, power corrupts and absolute power corrupts absolutely.

I believe the Eclipse community specifically, the open source movement in general, and the internet as a whole, are incredibly powerful forces that will do more to change our global society than perhaps any political force ever has. The internet has brought down barriers to the flow of information and to the spread of ideas. It's ignited a new type of flame, the open community, that we all feed. We cannot help but influence it and we should be particularly wary of those who will coerce it for the gains of a small few. Rest assured that those who are too enamored by power will be consumed by it. A global force manifested in the internet is sweeping the planet and it empowers us all. The flow of information is no longer controlled by the editor of a journal , the publisher of a book, or the CEO of a corporation. We all have direct control over the information that flows around the globe, often within milliseconds of when we produce it. Others can rapidly build on these ideas and of course in the end, the whole is far greater than the sum of its parts.

So nurture power, exercise it transparently, and share it wisely. Individuals control the world.

Saturday, 10 November 2007

Fall Musings

The EclipseCon submissions are picking up their pace though no doubt there are quite a few people waiting until the last minutes to sneak in their submissions. Speaking of sneaking, look who was sneaking around my pond this lovely sunny fall morning.


I took these pictures out of my bedroom window. There were actually two of them, but I didn't get them both on camera.


Darin mentioned that foxes might help take care of my diversity problem, i.e., the mink that was eating all my frogs. Ironically, that problem took care of itself: she electrocuted herself under that rock shortly after last week's photo was taken. I wonder if there is anyone else I could convince to crawl under that rock, but clearly I digress...

With regard to EclipseCon, I highly encourage folks to think about giving short talks. I know you don't get free attendance for those, but they are very little work to prepare, they will given you a chance to talk about the cool things you are doing, and of course, most importantly, they will give everyone else a chance to find out more about you and your cool work. This is likely to help you establish contacts with like minded folks and meeting people is half the fun at EclipseCon. There are a great many short talk slots and not so many submissions for them, so the opportunity is ripe and I highly recommend folks planning to attend give a little more thought not just to attending but also to participating. Don't be shy. Help make this the most diverse conference ever. Show us your colors.


I'm looking forward to the runtime summit too. Like the Eclipse platform, EMF is well recognized as a basis for implementing tools, but it's not so well recognized as providing a very flexible and powerful runtime. EMF's core runtime even works stand alone with no dependencies on any other Eclipse runtime jars and the 2.2 runtime works with Foundation 1.1, so it can even be used on small devices. I think it's important that Eclipse's technologies be recognized as a powerful basis for runtimes as well as for tools, and this summit can help with that. It's one of the fallacies of our industry that there are tools and there are runtimes, and never the twain shall meet. Think of how much more productive developers could be if they can use common technology as the basis of both.

I'm also excited because Tom, Boris, and I are investigating supporting the core EMF runtime and the EMF edit framework that works with GWT. Tom is making very good progress. He's one of my favorite people at Eclipse because he's so incredibly helpful. I think he sets a really high bar as one of Eclipse's outstanding citizens. Check out his offer to help provide and maintain a 3.3 language pack. He's like a ray of sunshine on a frosty morning.


I've also been keeping in eye on the DTP newsgroup. I'm actually I'm a closet newsgroup junkie. Oops, I guess it's best to not say that out loud. In any case, I watched with interest the thread by Jeff Ramsdale about his offer to develop an EMF Open Data Access component. I think this will help feed EMF data into BIRT, so I'll bet a great many people will derive value from that.

Closer to home, the new Mint component is being provisioned now and there is yet another new proposal for a Temporality component. I'm very pleased that the modeling community is growing so incredibly fast. It seems to me that diversity breeds more diversity as I watch more and more people wanting to get involved in the rapidly growing set of components. I also had a few private conversations with companies looking to join the party, so I expect the pace of growth the pick up further. Eclipse is a great place to be!

Tuesday, 6 November 2007

Kudos to Eclipse's IP Team

David Sciamma submitted Contribution Questionaire 1862 today for the contributed code base of the new EMFT component that will provide support for graphical Ecore editing. I'm really very excited about it!

Imagine my pleasant surprise when it was approved via the parallel IP process in less than 1 hour. Incredible! Cheers to the IP team!


Don't over do it though!



For personal reasons, I won't be able to got to OSSummit Asia after all. So Crusty (guess which one is Crusty) won't get to meet MLP until another trip.

Friday, 2 November 2007

Coping with Diversity

Like the modeling community, orchids are extremely diverse. They represent the largest family of flowering plants, which might surprise you since they seem so exotic and rare. It surprises me that the modeling community has yielded no EclipseCon 2008 submissions yet! But I'm hopeful the community will soon produce some blossoms because, as if by good omen, my Cattleya just went into bloom the other day. Not only does it look lovely, it smells wonderful too!


There was a heavy frost last night, so that pretty much does in the last of the late bloomers. Come on modelers, don't be late bloomers like my Delphiniums.


You'll be frosted if you miss the November 19th deadline that's rapidly approaching!


And then, not unlike my Euonymus, you're likely to turn scarlet from embarrassment for being left out in the cold.


So be first and propose lots. It's a predatory world out there.


I was shocked to find a mink at my pond just a few hours ago! This sure explains a lot though. The missing koi, the dwindling frogs (note what's hanging out of her mouth), and the sparsity of this year's tadpole population. See the rock behind her? She just dove into the water and has her burrow in there!


Oh my goodness. I can't just send the dogs to chase her away like the heron either. I'm not sure what to do about her. At least she hasn't chewed a hole in the liner like that darned muskrat did a few years back.

Ah, diversity, it's a double edged sword...

Wednesday, 31 October 2007

A Bug and Some Spooks

As I threatened in my previous blog, here is the result of this year's pumpkin carving extravaganza.


Frightening creations aren't they?! This bug is a distant relative of our much less scary bugzilla mascot. I expect these creations, along with the smoke machine and the moans and groans sound effects, will scare all the little kiddies away so that we'll have lots of candies left over for ourselves. Fortunately we had specialized pumpkin carving tools that are very dull so we didn't need to make any claims against our accidental death and dismemberment insurance. I do wonder though what a thumb would be worth. After all, the space bar is very big so you can hit it with either thumb...

I managed to get the changes for 207671 committed. This generalizes the support for attribute access and even allows attributes to be updated. I could imagine that this might be used to support locking and unlocking resources. I hope it's all in good shape in time for next week's M3 build...

We're also starting a discussion about creating a modeling package for all the avid modelers of the world.

I found the article "Empowering the Masses with 'Oslo'" interesting. I thought Eclipse already empowered the masses. Maybe they'll use EMF4NET and make it all EPL? But then again, I ate that yummy looking shiny red apple the nice old lady brought to the door earlier and it seems to be making me a little woozy...

Friday, 26 October 2007

The Garden is in Decline but the Community is in an Upswing

The end of October is quickly approaching, so it's almost time to carve up the pumpkins. I planted my own too late this year and had to buy them, and because it was so dry, the pumpkin selection is kind of poor. Expect some photos of my carving talents in the days to come! But don't expect me to be cackling over a cauldron any time soon.

The garden is almost done for the year. If forecasts prove correct, we'll get a killing frost on Monday. But there are still some beautiful things out there.


Bernd sent me a link to this song that I'm sure many will find as funny as I did; I had to wipe the tears from my eyes. Note however that if you're inclined to see blasphemy where others see innocent humor, don't bother going; I can't imagine anyone taking offense, but I don't like to offend anyone.

I'd like to brag about the modeling community just a bit. There are just so many cool things going on! It's like we're having a great party and everyone wants to come to it. The contributors are schooling of fish:


We have new components in the works for model-based web services, graphical Ecore editing, textual Ecore editing, and improved OCL integration. And soon I expect we'll even have EMF for C#, and some excellent tools for improved JDT integration.

I strongly encourage the modeling community to come forth with their EclipseCon proposals. Tutorials are free this year so expect lots of attendees. The modeling-specific tutorials will be available in eight two hour slots, so our community can mix and match to suit their specialized interests. Don't wait until the last minute! I want to hear all about what other people are doing so I'll avoid using up any slots myself. Don't be shy, we all want to see you:


At the risk of having yet another interrupt mechanism to destroy my productivity, I wanted to advertise the fact that Nick has convinced me to hang out on the IRC channel for #eclipse-modeling. Hopefully folks will hang out and help each other. So far it's been pretty quiet, so I sure hope I'm not opening the floodgates. Sometimes I feel like a conductor when what I really want most is to play a musical instrument myself...

Saturday, 20 October 2007

Jane You Ignorant Slug

Many of you will likely recognize the blog's title as the sanitized start of a totally unprofessional Saturday Night Live "Point Counter Point" rant between Chevy Chase and Jane Curtin that was more focused on personal attacks than on addressing actual issues like mature adults. Of course it was funny on Saturday Night Live, but I find it distressing to see the analog of it in Eclipse's blogosphere this week. I suppose some might even consider the Release Review Theme Song to be in this vein; I hope that's not the case and that certainly wasn't the intent. I think it's a testament to Bjorn's professionalism how he reacted to the obvious malcontent of the community in his usual constructive way.

All this reminds me of this little nipper I encountered on one of my dives in January. As I got ready to take his picture, he decided to dart out at me to nip my hand.


I considered it a personal attack and made a few threatening gestures in return. I suppose I had violated his space and he felt justified in asserting his dominance in that space. Be careful little fishy!

Now back to the issue at hand. I'll be the first to admit that Bjorn and I have had our differences. But guess what folks, intelligent people will often have differences of opinion and passions will often get the better of us. The more professional among us will use such things as a learning opportunity to see a perspective that might otherwise escape us, and will try to keep the heated debated focused on the subject matter rather than on denigrating the opposing party. Before folks feel compelled to knock me down off my high horse, don't worry, I often fall off all on my own. I'm far more likely to be swayed by emotions than most.

With regard to the issue in question, is Eclipse free, I don't agree with all the arguments Bjorn put forth but I certainly see he has a point, even if it does involve splitting hairs. Sometimes splitting hairs can be informative and even entertaining. The argument was made that by his reasoning even free beer isn't free, because you have to drink it. That's right; it might cause weight gain, and that might have health implications, the treatment for which might not be entirely free. And the over zealous free beer guzzler who killed people driving home might find that the family of those he killed doesn't consider the beer to have been free. And in some countries in the world, the folks who supplied the free beer might find that not only did the free beer cost them money but they're also held responsible for supplying it so copiously that folks go home drunk. In any case, the debate is an interesting one, and I don't see why it's necessary for it to degrade into a personal assault.

The community needs to remember that Bjorn as a representative of the Eclipse Management Office has the unenviable task of being the rule enforcer so while it's always easy to find fault with the messenger, as professionals we ought to know better. As a call to action, committers should take note that as a community it takes almost no advantage of the fact that we have five voting board members who can and do work in our interests to effect change in Eclipse's policies and processes. I doubt that most folks even realize we exist and likely would be shocked to understand just how much sway we have on the Eclipse Board. Keep in mind that many large corporations are paying $250,000 for a seat at the table, not to mention the $1,000,000 they are obligated to invest in active contributors. The committer community has five of such influential seats serving their interests and yet when was the last time someone had anything constructive to suggest on our newsgroup?

We're all responsible for making Eclipse better, so while ranting about frustrations is only human, acting on those frustrations constructively in order to harness the underlying passions for the purpose of effecting real change is what professionals do.

Thursday, 11 October 2007

Eclipse Summit Europe Day Three: Sessions and Chats

I stated the morning with Jörg Sievert's talk about what venture capitalists like about open source. The money of course! You might wonder how giving something away for free can be a good business model, but there are certainly enough examples where building an open source community is the best way to gain market dominance and that in and of itself generates value...

After the session I had a very nice chat with Brandon Ulrich and Balazs Banfai of B2 International about their use of EMF in the Open Healthcare Framework. They really appreciated Marcelo's help with their SOC project. Meeting people and understanding the issues they face is half the fun at these conferences!


I managed to track down Tom Schindl again too. He didn't try to run or hide.


Tom is self employed and hence gets to work on whatever he chooses. That must be cool! I asked him why he's so incredibly helpful on the newsgroups and so generous with sharing his cool work. He explained that he learned a great deal from the platform code and benefits so much from the help of folks like Boris Bokowski and other platform committers that he feels compelled to give back in return. So as the old saying goes, what goes around comes around. Sharing and being helpful tends to make other folks share and be helpful, so when there is such an obvious return on investment with folks like Tom, it helps to induce and even stronger feedback loop. That's what makes Eclipse such a great community. I was going to take a cell sample so we could clone him (under the EPL license of course) but I suspect there are laws against that.

As Wayne noted in his blog, I spent a lot of time chatting with folks, though perhaps he over emphasized the talking verses the listening. Several people expressed their gratitude for the help they got on newsgroups. I'm always tempted to say "Don't take it personally, I help everyone" but you have to be careful that a humorous comment isn't misinterpreted.

In the evening, I had dinner with a few of the folks who didn't have to leave immediately, like Lynn, Don and Gunnar, so that finished off the day very nicely. All in all it was a most excellent event!

I'm already looking forward to OSSummit Asia and of course the next EclipseCon. Speaking of which, I'm going to have to span all the modeling newsgroups to call for EclipseCon submissions. It's that time of the year again!

Wednesday, 10 October 2007

Eclipse Summit Europe Day Two: Big Models

Well, I'm exhausted from today's Big Models work group! Here's a snap shot of the group and of the room in which I spent most of the day:


The "let's pick on EMF" day ended well! But I'm too tired to say much about it. Axel, Simon, and Diego were the major instigators from SAP but they, and all the other folks, picked on EMF in such a nice way, it almost didn't feel like critique (much). Actually, it wasn't really so much picking on EMF, it's just that scaling problems are hard no matter what technology you use.

I got to meet some of the managers from SAP as well, so I'm very hopeful that the SAP executives will overcome their conservative ways and take the EMF plunge. You have to take risks in life to reap it's greatest benefits. It was just great getting to meet Axel, Simon, and Diego in person. It will be so cool if they get to work on and with EMF...

Rich and my demo also went well, I think, but it's best to let the audience be the judge.

And I finally got to meet Tom Schindl, though only for a few minutes. But I know what he looks like now, so I'll track him down tomorrow. He can run, but he can't hide!

The reception was nice as well, though I found out a disturbing secret. Mike Milinkovich is a closet Modeling Redneck. Apparently he believes, and I quote, "Modeling is stupid" . Rich and I were going to bitch slap him; actually mostly just me, but Rich probably would have helped because he's ever so helpful. Instead I did the politically correct thing and explained that the only thing more stupid than drawing a box called X with a compartment called y, would be to write an interface called X with getY and setY methods, a class classed XImpl, with a getY and setY methods as well as a y field and method bodies to update y, a factory to create an XImpl, some code to serialize X's y feature, and finally some code to deserialize an X's y feature. Around this point he started to glaze over so I'm sure I was highly convincing that not only is not modeling stupid, but so is Ed. He's a very insightful person!

Tomorrow I'll get to go to some of the talks so that will be cool. Stay tuned...

Tuesday, 9 October 2007

Eclipse Summit Europe Day One: The Modeling Symposium

The Modeling Symposium was really well attended with roughly 35 people. We traded for a larger room with one of the less well attended symposiums. I got a snap shot of all the folks in the room.




Markus Voelter gave a quick introduction and I talked very briefly about what's happening in EMF and the other Modeling projects. Then Bernd Kolb and Peter Friese talked about the Model Workflow Engine. It provides a language to write scripts that drive Bean-like classes representing the components within a workflow. It includes debug framework integration so you can track the activity of a flow. Folks were interested to see a sample running under debug control, so Bernd was under the gun to produce that quickly. Someone asked why not use Ant? MWE has more specialized control mechanisms; it also has an Ant task and they are working on being able to call out to Ant.

There was a presentation about Product Line Unified Modeler by Aitor Aldazabal of the European Software Institute. This involves managing variability of a line of related products via a decision model. Eclipse was a good choice because they wanted OSGi support for deploying on devices. They use Ecore to define models and generate a basic editor as well as using GMF for graphical support. They also use OCL for defining constraints on configuration validity as well as oAW for scripting the process. They need a distributed architecture so are looking into MDDi.

Then Bernd and Peter came back with a quick demo. It's very cool that you can step into the various parts of the flow processing!

Holger Papajewski of Pure Systems presented about Integrating Model-Driven development and Software Product Line Engineering. It was quite closely related to Aitor's talk. They are very happy with the choice to use Eclipse, which was a choice made very early in Eclipse's public life. We noticed a pattern that the talks all used oAW, but Markus denied selecting based on oAW usage, but that just made it more fun to tease him about it. This project manages variants and variability using feature models. The variants are generated using a decision model. They use BIRT for report generation. They are moving over to using Ecore to describe their models.
And they have a need for scripting the types of changes they commonly make.

During the break, I talked to Stephan Eberle who is at TNI-software now. I also chatted with Miguel Garcia and helped him set up his OCL tools demo on my machine. This was the only meeting I've ever been too that was ahead of schedule. Markus runs a tight ship! I also talked to Reinhold Bihler about the C# component for translating EMF's runtime for .NET; Mikael from INRIA was quite interested in this.

Dimitros Kolovos of University of York, an Epsilon committer, talked about automating repetitive tasks. Their project provides infrastructure for implementing task-specific languages. Epsilon Object Language is based on OCL and includes support for comparison, validation, merging, and transformation. He showed how to extract a class into an interface automatically, transforming references to the existing class to refer to the new interface instead. They plan to look at converting a recorded change description into a generated wizard skeleton.

Gabriele Taentzer of Philipps-Univeristat talked about supporting complex editing operations using in-place transformations based on a Transformation Rule Model that lets you describe what needs to be done to transform a graph. When I spoke with her at lunch, she expressed an interest in starting a model refactoring component in EMFT. Cool!

Maarten Steen of Telematica Institute talked about using Business Process Designs to generate code. They use QVT to transform between models. There was quite a bit of discussions about what parts of QVT are currently being supported or planned in the Modeling project.

Miguel Garcia give his impromptu presentation about his OCL tools and the Emfatic work referring to his home page: http://www.sts.tu-harburg.de/~mi.garcia/Promotionsprojekt.html

At the end of the morning, Markus collected topic for afternoon break out discussions.
  1. Would be a nice to have one QVT implementation.
  2. Dashboard for model users; making the tools more usable.
  3. Organization of the Modeling project. How to make the overall project more organized?
  4. IP? Autosar has a private metamodel...
  5. Validation and OCL constraints.
  6. Scripting and orchestrating the tools.
  7. Scalable support for big models.
  8. What's happening with M2T?
  9. Textual modeling framework.
  10. Integration of textual and graphical aspects of DSLs.
  11. Weaving instances and determining correspondence between instances.
  12. Visualization of complex models.
We voted on our favorite topics and used that to determine which discussions should happen sequentially. After that we had lunch.

As part of the "Better organization" discussion lots of issue were raised. How to use all the different projects in a cohesive way to achieve a particular result? Many people invest a lot of time learning poorly documented tools to understand which ones will help contribute useful capability for their task at hand. We need better summaries of what projects really provide. It's hard to find the information you need. The ability to use all the frameworks in an end-to-end solution is an important need to address. I pointed out that what would be really good would be if users help to focus on building up the information base that documents what they've learned to help make life easier for the next set of users. I.e., the community can contribute to the solution via the wiki.

Markus argued that we need better leadership, i.e., folks who understands and promote the big picture with less particular focus on a specific project. I think that comment was directed mostly at me rather than at Rich, who is busy working on a book for how to use the various Modeling project technologies to build a domain specific language. Hey, if the shoe fits, I put it on! There is also a problem of reinventing technology; researchers tend to like to do this. Overall, a dashboard for technology in Modeling project, like the one for GMF would be appreciated. It was observed that it's not necessarily in the funding company's best interests to make open source so competitive it competes with their products or services, so the community really needs to step in to help polish the open source results. It was also observed that academic research funding is often driven by folks relabeling their work to fit into the special interest of the day without actually changing what they are doing. Folks were also concerned about competition with Microsoft's DSL tooling; obviously Microsoft knows how to polish their results. In general, there are perceived to be too many projects with overlapping scope and with vague interrelations. In the end, we don't need yet more solutions to the same problems, we need a smaller number of well-integrated high-quality solutions. I'll need to think about all this a lot...

As a prelude to tomorrow's Big Models meeting, the issue of scalability was raised. Solutions that work well for smaller models will often not work so well for larger models. It was noted that unloading a large model will actually increase the memory consumption by converting objects to proxies. The objects are detached from the resource but they maintain all their connections,
including their containment tree so any reference to any object in the tree will keep the whole tree in memory. One could unset features to eliminate the containment connections between the objects and thereby allow the individual unreferenced ones to be collected. Fragment paths are seen to be quite large and fragile, though that space is transient while the ID overhead stays around longer. Some folks need to track all instances of some specific type so I pointed out at a specialized EContentAdapter could maintain that information on the fly to avoid visiting the whole model each time.

The issue of large models that are too big to fit all in memory came up, but even without EMF, there is really no solution to this problem. One needs to split them into smaller pieces to make working with them manageable and to reduce change conflicts; cross resource containment can help with splitting large models into smaller pieces. Repositories can be a solution for the search and query problems by maintaining caches and indexes; it can understand the deep structure of what is saved. Also, the EStore API can be useful for separating the data from the EObjects that carry the data; CDO is using this approach. In the end, the best way to make things scale is to have a larger number of smaller resources rather than a small number of very large resources. One can always process the smaller resources one at a time, but a large resource taxes pretty much any technology.

There was a slightly confusing discussion about end user integration because defining an end-user is tricky in this meta meta world. But we decided that by end-users, we mean the modelers, i.e., those folks who will use the Modeling project infrastructure to build models, tools driven by those models, and utilities to manipulate those models. It would be awfully nice to make the tools feel more like the JDT with proper end to end integration to handle common issues easily. Scripting or workflows to perform more complex tasks as part of a build would be a time saver and error preventer as well. Make tools simpler by hiding incidental complexity...

It was a very interesting but tiring day. Rich arrived at the end and I sat down with him to go over the demo we do tomorrow. I'm a little ill prepared. I hope I don't screw it up too much!

Finally we went out for the sponsors dinner organized by Ralph.


Tomorrow's Big Models meeting should prove fun as well. Stay tuned...

Monday, 8 October 2007

Eclipse Summit Europe: The Day Before

My flight from Toronto to Frankfurt yesterday afternoon was on time and very nice. Out of tact, I won't describe just how nice it was. The flight from Frankfurt to Stuttgart this morning was only slightly late. And the taxi ride was fast, i.e., 170km/h at times. I certainly got to the hotel in good time and they had my room ready when I arrived, so I could catch up on a bit of lost sleep.

I had a little bit of time to explore before dinner. The forum looks to be a nice venue.


It didn't take me long to find a cool garden too.


I ran into Don and Lynn, but they were eating early so I walked with them to their restaurant. Later, this snake caught my eye on the way to dinner with the Architecture Council folks, Michael, Pavel (I hope I spelled it right), Bjorn, the two Dougs, and Jeff.


It was a small but tasteful group and later we were joined by Ralph, Wayne and company, so it got to be a big group. Some of us left to make room for the late arrivals, and we strolled through the pretty town in the dark.


I'm looking forward to the modeling symposium and the sponsor's dinner tomorrow night.

Stay tuned for the next chapter!

Friday, 5 October 2007

Is EMF going to replace MOF?

Ian Bull directed my attention to a Model Driven Engineering poll which asks "Is EMF going to replace MOF?" The four choices are quite amusing:
  • Yes, MOF is about dead. That's really sad. I didn't even know it was ill!
  • It may influence it, but both will stay. This sounds a bit too future tense to me. EMOF and Ecore are effectively equivalent---we can read and write Ecore as an EMOF serialization---and that's not an accident. MOF was split into EMOF and CMOF (essential and complete) because of Ecore's influence. When we started work on EMF, MOF seemed to have a lot of nonessential things, so we eliminated those.
  • EMF will never supplant MOF, MOF is great. Since Ecore is an implementation of EMOF and existed before EMOF, I'll be just as happy if we compliment MOF rather than supplant it. If MOF is great, so is EMOF, and so is Ecore. Transitivity is such a useful property!
  • EMF is just for Java, it is too specific, MOF is great. Well, EMF is clearly a MOF implementation targeted to Java. I'm not sure if a Java implementation can be too specific for Java, but if so, I guess it could also be not specific enough, or it could hit the Goldilocks target of being specific but not too specific. Coincidentally, Reinhold Bihler is working on a .NET version of EMF and I know other folks have generated C from it. His version will be just for C# so it might be too C# specific but I expect it will be just specific enough. I'm still waiting to find out from Mike if a C# project can be hosted at Eclipse. That would be a first I think...
So in the end, I think all the choices are good ones, except maybe the first half of the last choice.

Like so many other folks, I'm very much looking forward to Eclipse Summit Europe next week. The Architecture Council group, of which I am a member, is planning to have dinner, which will of course accomplish next to nothing and hence will completely live up to the expectations based on the council's past performance. Oops, did I say that out loud? Just a little joke! Besides, I'm just quoting Bjorn who's never afraid to say what needs to be said. In all seriousness, the newly reformed council has yet to meet, so time will tell if we can become a functional body. If we can just become good mentors for the community we will have taken a positive step in the right direction.

On Tuesday there will be an all day Eclipse Modeling Symposium. Last year's symposium was way cool, so I'm particularly looking forward to this one. On Wednesday there are all day meetings about Big Models to look closely at issues of how EMF can best help support a massive collection of interrelated models. And by the way, don't ever Google for "big models". Oh my eyes. Some images are hard to erase after having been seared onto your retinas. My partner in crime, Rich Gronback, and I will be giving a cool demo. And of course modeling is ever so popular in Europe so there will be cool talks about oAW and compare. I'd never heard about Medany Platform before, so I'll be interested to find out about that!

Lots of people I've never met will be there, and meeting people is more than half the fun. I'm particularly excited to meet Tom Schindl. He's so incredibly helpful on the newsgroups and is doing such cool things. I can't wait.

So no garden pictures this time, but I'll leave you with this photo I took a few years back in Grenda with a rainbow to remind us that diversity in our community is the key to its long term growth: