randomice.net

I am currently preparing a new release for my GenGMF project. Because the new meta model contains important but incompatible changes I have migrated the GenGMF tooling to a new name space and created a migration script for converting the specific editor models. The new meta model is much smaller than the old one which results in smaller models — I’ve eliminated the need for the mapping elements in the templates. To make the migration as easy as possible I’ve created some helper functions to move corresponding attributes and references. Only the “real” changes in the meta model are migrated using a Xtend script.

To demonstrate the facilities of the CrossNamespaceCopier I’ve created a small meta model…

As you see the Class2 from the “http://source.namespace” has been eliminated in the “http://target.namespace” and both attributes have been moved - attribute2 to Class1 and attribute3 to Class3. In order to migrate a model instance one has to call the CrossNamespaceCopier which copies the objects while migrating the name spaces according to rules previously set. OtherClass objects from the “http://other.namespace” will be copied as they are. All references and attributes which could not be automatically migrated need to copied in a small script manually.

extension CrossNamespaceCopier;

namespace::target::Class1 migrate(namespace::source::Class1 sc1)
:   let tc1 =
    // initialization for the copier, but the
    // let statement needs to be in the beginning
    (   crossNsInitStaticInstance()
    ->  crossNsSetupNamespaceMapping(
            "http://source.namespace",
            "http://target.namespace")
    // the content for the tc1 variable
    ->  (   (namespace::target::Class1)
            crossNsCopy(sc1)))
    // skipping Class2 in source
:   tc1.setClass3Reference(
            (namespace::target::Class3)
            sc1.class2Reference.class3Reference
            .crossNsCopy())
    // pull up attribute2
->  tc1.setAttribute2(
            sc1.class2Reference.attribute2)
    // pull down attribute3
->  tc1.class3Reference.setAttribute3(
            sc1.class2Reference.attribute3)
    // uninitializing
->  crossNsReleaseStaticInstance()
->  tc1
;

You will find the CrossNamespaceCopier as well as the demo files contained in a zip file.

GMF, the Graphical Modeling Framework supports the creation of graphical editors. For beginners it is very hard to learn. The included wizard has a lot of disadvantages, but it is o.k. for a start. Furthermore the GMF models are very complex and hard to handle. There are different solutions to shorten the time needed for creating a graphical editor:

EuGENia

… supports the development of GMF based editors using annotations in your metamodel (*.ecore) - preferably generated using Emfatic. Dimitrios Kolovos has written a nice tutorial and created a screencast.

ATLflow

Like in EuGENia - annotations in the metamodel are used to create a graphical editor. It is part of a complete tool chain for model transformations based on ATL. It is used for bootstrapping parts of ATLflow itself.

GenGMF

… uses a completely different approach. The GMF models are created from template-like tree structures. A template consist of GMF elements - just ready for duplicating for each metamodel element it is associated with. It is recommended to have some experience with the GMF models, before starting with GenGMF. GenGMF has been developed to support the creation of editors with a lot of metamodel elements.

Both annotation based solutions are not able to cover all the features possible with GMF, because the GMF models are created using the information stored in the metamodel. The template based approach GenGMF offers a lot more flexibility at the cost of a more complex model.

I have just seen, that by now xText supports external references out of the box. This is a long awaited and really useful feature. Thanks a lot.

Step 1 (real live): You have the wish to get a cup of tea of “Pai Mu Tan”.

Step 2 (model): You are creating a wish-model containing an element of type “Cup” which has an attribute named “content” of type string and the value “Pai Mu Tan”. The model is the digital representation of a real-life-wish.

Step 3 (metamodel): You want to create other wishes too and you are designing a metamodel. The wish-metamodel contains a the root element “Wishes” containing a many-containment reference “wishes” to the type “Wish”. The abstract type “Wish” is derived by the types “Cup”, “Book”, “FreshAir” and “OtherWish”. “Cup” has an attribute “content” while “Book” has an attribute “title” of type String. “FreshAir” does not need an attribute and “OtherWish” has no meaningful attributes. Using the wish-metamodel you could express a lot of wishes.

Step 4 (editor): You want others to express their wishes. Let’s create an editor, they could use to do that. Using Eclipse and your metamodel it is really simple to create an EMF based tree editor. You are happy.

Step 5 (great models): Your models grow (you have extended your metamodel with other wish-types) and you want to group your wishes by occasion (Birthday, Christmas, other) if they are of long-term, short-term or just-now. You are doing that by extending the metamodel with other types (AbstractOccasion, Birthday, Christmas, AbstractWhen, LongTerm, ShortTerm, JustNow) and some connection types connecting your wish with when they should be active. it is hard to keep the overview about all your wishes - you want a better editor (which is a wish-type of it’s own).

Step 6 (graphical editor): You have chosen GMF as your editor framework. It is great - you could express all you want - your wishes, the occasions and whether your wishes are more short- or long-term in a model driven way and without writing one single line of java-code. Now you have the overview about all the wishes.

Step 7 (more wish-types): Every time you create a new wish-type in your metamodel you have to copy-and-paste-and-change some parts of the GMF-models to express the editor object for your new type. You want more abstraction like a templating engine for GMF-models.

I am currently developing such a model-templating engine called GenGMF. You could create a template-tree for the GMF-Graph and for the GMF-Map models having place-holders for the type-names you want to instantiate (e.g. “__TYPENAME__NodeFigure”) and some modelled instructions how to instantiate the tree in the GMF-models. It is even possible to change the instantiated trees on-the-fly. For example - I reengineered the sample editor from one of my last posts. The rectangle and the elliptic nodes are instantiated from the same template (which only knows rectangles). A XTend-based creation Filter changes the Rectangle to Ellipse - the rest of the tree is the same. Post processing (also via XTend) is also available to insert more stuff into the generated models.

Do you see the difference between the following two pictures?

It was the result of the CatChaser pinning two balloons and part of one of the eight talks held at the Eclipse DemoCamp in Hamburg. A lot of interesting projects and concepts where presented. They made a video of the talks which will be available soon.

One of the intended presenters wasn’t available. They asked me to talk - as substitute - about MetamodelDoc. As I had prepared my slides for the DemoCamp in Berlin already - I agreed. The slides are - of course - available.

Update

After the event in Hamburg the event in Berlin was a success too. There are a lot of interesting projects. One of them - ObjectTeams - I will give a try. It could be described as sophisticated and object oriented AspectJ with dynamic binding (well - ehm …, the language constructs are not the same) and it integrates very nicely into the JDT environment (by replacing the JDT-core plugin :-/). An interesting feature is - you could de-/activate an aspect (it is called Team here) during the lifetime of an object and on a per object basis.

As you may have noticed - there was no Eclipse DemoCamp campsite available in the eastern part of Germany. After some discussion - there will be a “newthinking store”-campsite in Berlin on the 19th December starting at about 18:⁰⁰.

I am currently writing an oAW-based documentation generator for Metamodels called “metamodeldoc“. Currently only Ecore based Metamodels are supported but UML is planned too. As an example I’ve generated a documentation for the Ecore Meta(meta)model which is also a model instance of it self and placed it at http://metamodeldoc.randomice.net/ecore/

At the Democamp I want to talk about some internals of metamodeldoc.
If you are interested in Metaprogramming and all the other cool stuff… just append your name to the
end of the list of Attendees (or even Presenters) at http://wiki.eclipse.org/Berlin_DemoCamp.

You will need an https://bugs.eclipse.org/bugs/-Account to add your self to the list. Don’t want to register? (it doesn’t hurt!) Just leave a comment and I will add you to the list.

who likes to organize an Eclipse DemoCamp in the eastern part of Germany (preferably in Berlin or Leipzig)?

From: Lynn Gayowski
Sent: Wednesday, October 31, 2007 4:16 AM
To: Enrico Schnepel
Subject: FW: demo camp

Hi Enrico!

Eclipse DemoCamps are being organized locally by committers and member companies. We haven’t had any volunteers for eastern Germany yet.

Here are the guidelines for organizing a DemoCamp: http://www.eclipse.org/community/democamp/organizedemocamp.php. If there are any committers or members that would like to help, we’d be happy to support the event.

Regards,
Lynn Gayowski
Marketing Events Manager
Eclipse Foundation, Inc.
www.eclipse.org

—–Original Message—–

From: Enrico Schnepel
Sent: Wednesday, October 31, 2007 5:39 AM
To: news (at) eclipse (dot) org
Subject: demo camp

Hello,

I would like to attend to a demo camp (http://wiki.eclipse.org/Eclipse_DemoCamp) but they are only located in the western part of Germany (counting four) and none is in the eastern part of Germany. Is it possible to make a fifth demo camp within Germany e.g. in Berlin or Leipzig?

Regards

Enrico Schnepel