Graphical Modeling Framework/Versions/GMF 2.2

• Documentation
• FAQ
• Troubleshooting
• Get Involved
• Contributors Area
• Ecosystem

GMF

Website

Download

Dev Builds

Update Site releases milestones

Community

Mailing List • Newsgroup • IRC

Bugzilla

Open

Help Wanted

Bug Day

Source

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

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 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=243154, https://bugs.eclipse.org/bugs/show_bug.cgi?id=243156). 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 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=242880 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:

New GMFGen URI

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 http://www.eclipse.org/gmf/2009/GenModel

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.