Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Graphical Modeling Framework/Versions/GMF 2.2
|Update Site releases milestones|
|Mailing List • Newsgroup • IRC|
| GMF Notation: View CVS repo|
- 1 2.2 M1
- 2 2.2 M3
- 3 2.2 M3
- 4 2.2 M4
- 5 2.2 M5
- 6 2.2 M6
- 6.1 Escape characters are supported in QVTO-based
- 6.2 ViewFactories are history
- 6.3 Generated palette customization
- 6.4 Legacy xpand templates were moved to separate plug-in
- 6.5 Migrate to new QVTO-based xpand action was moved to project menu
- 6.6 New GMFGen URI
- 6.7 UTF-8 template encoding
- 6.8 Clean code
Custom Preferences and Preference pages
Besides, not all the preference pages are generated now, see Bugzilla 247542
DIAGRAM_PREFERENCES_HINT access (Bugzilla 250767)
Single template for asserts (Bugzilla 249301)
Improved merge for plugin.xml
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
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
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" 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.