Community
Participate
Working Groups
GMFT recognizes increasing popularity of XCore inside the Eclipse modeling. In order to be consistent and support currency, GMFT needs to consider using an XCore/XBase. Within Kepler release the usage will be limited to GMF-T internals and most probably will not affect the end user (toolsmith's) experience (which is the next step to be considered for later release). We see the following steps of this migration: - Provide XCore versions of GMFT input models - Migrate as much as possible of the QVTo helpers from templates to the XCore-defined operations or derived features. (however backward compatibility should be taken into account here, it is possible that some of the QVTo helpers are overriden in the custom templates). - In the M2M transformation consider using the same process as it is done within the X-framework to transform XCore to ECore. Replacing the actual QVTo helpers with the operations defined within X-framework will reduce dependency from QVTo inside the GMFT code-generation and thus should help with getting back to using the standard templates language (see Bug #386838).
- All QVTo helpers used for generation are migrated to Xtend as part of Bug #386838 - Actual migration to Xcore to be reconsidered for 4.0
I've migrated a set of ecore models used in a GMF editor to xcore, and I'm running into problems: GMF map editor fails with "Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist." Here is MANIFEST.MF: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: mybundle Bundle-SymbolicName: mybundle; singleton:=true Bundle-Version: 0.1.0.qualifier Require-Bundle: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport, org.eclipse.emf.ecore.xcore;visibility:=reexport, org.eclipse.emf.ecore.xcore.lib;visibility:=reexport Has any more work been done on this issue?
