Community
Participate
Working Groups
Actually the only runtime plugins GMF-Tooling generates code for come from the GMF Runtime project. Thus, the end diagram user does NOT need any of the GMFT plugins to run the generated diagram editors, only the toolsmith needs the GMFT plugins to model & generate the code. This limits the GMFT abilities because: - (1) it is difficult to write the generic code that works against every diagram using the knowledge of the structure of the GMFT-generated code. - (2) it leads to the glue code generated separately to EVERY diagram plugin created by the GMFT. E.g: (1) -- Every generated diagram has a class XXXVisualIDRegistry, which contains bunch of static methods that (among other things) describe which diagram node may be contained in which diagram/semantic container. It would be very useful if we instead (or in addition to) would had the interface IVisualIDRegistry that every XXXVisualIdRegistry implements -- it would allow to write the code that works with every generated diagram. The known examples are: - enhanced creation edit policies - better drag and drop support - generic hide and show related component, etc. However, without the ad hoc gmf-toling-runtime plugins, we don't have the place where to place this interfaces (2) -- Almost every GMF-T diagram has some gluing code which is generated identically without any respect to the input artufacts in MAP/GEN/... models. Examples are: - base parser implementations: classes AbstractParser MessageFormatParser, etc, - creation wizard pages that has a 95% of the code not specific for a concrete diagram type + 5% of the diagram specific code. - Node/Link descriptors for diagram updaters - XXXEditorUtils - small classes like XXXMatchingStrategy, LoadResourceAction, etc Even before the separation between GMF-tooling and GMF-Runtime, it was difficult to put this code into the GMF-runtime, because those interfaces does not have a separate purpose except of being use to generically handle obly the subset of GMF diagrams generated by GMF-T. Now, after the separation between the projects, the chances we may put the GMF-T specific interfaces into the "default" GMF runtime is very slim.
Adding Mickael Istria to CC, because I guess this will significantly affect the build procedure, an update site, etc.
A concrete use-case is the "GMF Runtime Lite" set of extensions that provides some bundles maintained by GMF Tooling, but that are intended to be used at diagram runtime. For example, if one wants to use SVG figures, he can add org.eclipse.gmf.runtime.lite.svg as a dependency in the GenPlugin element of gmfgen file, and the generator will produce code depending on this code. I don't see any big difficulty to introduce new plugins for runtime. We'll probably need a separate feature for these runtime parts. (adding Aurelien as CC since we are in the process of creating a runtime API on top of GMF, his GMF Runtime involvement could be useful)
Yes, technically I don't see a lot of problems here, except that I will probably need some help from Mickael with pom files, changing the update site generation and other releng staff. However, I would like to stress that it means that every diagram plugin generated by GMFT will require the END DIAGRAM USER to install at least one feature from GMFT. I think it was the main reason those plugins haven't been introduced at the Borland time. However the lite.svg (thanks Mickael to pointing out to this example) was there for quite some time already, so it is probably not that a big deal for a end user. Especially if we have a working update site, participating in the train, etc.
Hi, As Mickaël mentioned , it seems to me not so difficult to provide "new plugins for runtime". It is what has been done for SVG support. Don't hesitate if you have GMF-Runtime issues to discuss. Regards,
GMF-Toolng runtime is available since M7
