Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Graphical Modeling Framework/Versions/GMF 2.2

Dev Builds
Update Site releases milestones
Mailing ListNewsgroupIRC
Help Wanted
Bug Day
GMF Notation: View CVS repo

GMF Runtime: View CVS repo
GMF Tooling: View Git Repo, GitHub

2.2 M1

2.2 M3

2.2 M3

Custom Parsers

Bugzilla 244419

Custom Actions

Bugzilla 174961

Custom Preferences and Preference pages

Bugzilla 250772 Custom Preferences Bugzilla 247311 Boilerplate code for custom Preference Pages

Besides, not all the preference pages are generated now, see Bugzilla 247542

Ant Integration

Bugzilla 251588

Template enhancements

DIAGRAM_PREFERENCES_HINT access (Bugzilla 250767)

Single template for asserts (Bugzilla 249301)

2.2 M4

Improved merge for plugin.xml

Bugzilla 254532

Removal of deprecated code

There were few classes that were marked as @deprecated and were not in use in 2.1 release. Only couple of them were almost API (they resided in a public package, but we never documented their use), namely org.eclipse.gmf.gmfgraph.util.FigureQualifiedNameSwitch and its subclasses. Few internal classes from org.eclipse.gmf.internal.bridge.naming.gen package were removed as well (GenModelNamingMediator interface, its implementations and related classes)

M2M (QVTO) transformations

Bugzilla 259583 Both primary (gmfmap to gmfgen) or auxilary (in-place gmfgen modification) transformations are supported.

All GMF templates were migrated to QVTO-based Xpand

Xpand template engine was modified to use QVTO as query language (, All the existing GMF templates were migrated to new query language. You can find description of automated migration process here: GMF Xpand Migration howto

2.2 M5

2.2 M6

Escape characters are supported in QVTO-based

QVTO escape characters are supported in both .xtp and .qvto (a part of QVTO standard) files from now - see for the details. Migration tool was updated to produce escape characters then necessary.

ViewFactories are history

Bugzilla 257119

Generated palette customization

Bugzilla 236869 Provide id for ToolEntry to allow palette customization

Legacy xpand templates were moved to separate plug-in

All legacy GMF 2.1.3 templates were moved to newly created org.eclipse.gmf.templates.legacy plug-in. This plug-in is necessary for the migration action execution. Legacy templates will be automatically loaded from this plug-in.

Migrate to new QVTO-based xpand action was moved to project menu

"Migrate to new QVTO-based xpand" was moved from project popup menu to main "Project" menu. This action is available only if project with the legacy "org.eclipse.gmf.xpand.oawBuilder" builder is selected:



As one can tell from this wiki page, there were some changes in the GMFGen model since 2.1 release, hence model's nsURI was changed to reflect revision year and now is

Migraion is available as usual (action available from context menu only for old model files). When old model file is read, custom resource handler tries to bring the model up-to-date, going through a sequence of transformation (1.0->2.0, then 2.0->2.1 and finally 2.1-2.2). This means if one got a gmfgen file from the GMF 1.0 release, any read attempt, e.g. "Open editor" action, would show file contents migrated to present GMFGen metamodel state.

Note, if you have GMFGen models from M2-M5 of GMF 2.2, neither automatic migration will work, nor reconcile of GMFMap-to-GMFGen transformation result (with errors like "no 'parser' feature found in the metamodel"). The easiest way to deal with the issue is to open model file as plain text and update nsURI of the GMFGen model to reflect actual year (2008 -> 2009). With the change, re-open the file using GMFGen editor.

UTF-8 template encoding

Bugzilla 191653 Char encoding for xpand templates should be UTF-8. UTF16 LE/BE are supported as well. Respects BOM. Without BOM, tries to guess encoding, by far picking between old ISO-8859-1 and UTF-8. New templates get created in UTF-8.

Clean code

If diagram is in pixel map mode, we no longer generate getDPtoLP() invocations as there's no reason to pipe pixel values through identity MapMode.

Back to the top