Community
Participate
Working Groups
org.atl.eclipse.km3.StartUp loads EMF models, slowing Eclipse start-up. This is bad Eclipse practice. Suggestion: change AtlModelHandler.defaultModelHandlers to an initialise on first access policy: Map getDefaultModelHandlers() { if (defaultModelHandlers == null) { defaultModelHandlers = new HashMap(); ... load extension points } return defaultModelHandlers; }
I believe the KM3 plugin should register the KM3 metamodel. EMF provides some support for metamodel registration. For instance, the org.eclipse.emf.ecore.generated_package extension point does register a metamodel but requires generated code to be provided. Is there an EMF extension point appropriate for the KM3 plugin? If this is not the case, what other option do we have?
Meta-models registered in plug-ins should definitely use the EMF registration point, since this does nothing until an Ecore plug-in is started, and then populates the registry with model references, which are not resolved until the model is used. If you add: the missing nsURI and nsPrefix to PrimitiveTypes the missing instanceClassName to each of Bollean, Integer, String you can create an EMF project from km3.ecore, use genmodel to generate the model code and plugin. Using EMF 2.2.0RC6a there is one warning in the manifest due to an expecation that there will be a PrimitiveTypes.util package which is not generated for a DataType only package. Just delete the spurious package export. This can all quite happily fit in the existing km3 plugin. (no need to generate edit and editor or test plug-ins). The plugin will be more standard if km3.ecore is at model/km3.ecore. Since PrimitiveTypes is a regular requirement for ATL, you might care to factor it out as a separate model.
I do not consider generating Java code for the KM3 metamodel to be an appropriate solution: - the purpose of a metamodel is not to generate code, - the KM3 metamodel is not handled by Java code but by model transformations. Therefore, I believe it does not make a lot of sense to generate Java code for it. Isn't there a simpler way to register metamodels?
Generating Java code is the required solution today - because EMF has always been perceived as a Java code generator. EMF package registration works by installing instances of EPackage.Descriptor in the global package registry. These are converted on demand by the getEPackage() method. It should be possible for KM3 to install an EPackage.Descriptor that implements getEPackage() to load the Ecore file, rather than access the eINSTANCE of the generated code as EPackageDescriptor does at present. This would solve the KM3 problem, and could also form the basis of an interactively invoked meta-model registration. Perhaps a .metamodels file in a project with GMT nature would automatically install its content. I think we could contribute the alternate EPackage.Descriptor back to EMF so that it is automatically used for package registrations of the form <extension point="org.eclipse.emf.ecore.generated_package"> <package uri = "http://www.eclipse.org/gmt/2005/KM3" ecoreModel = "model/KM3.ecore" /> </extension> although this is perhaps twisting 'generated_package' a bit far.
Ed, The idea of using generated_package or a new extension point just like it (dynamic_package) to register the location of a dynamic package seems reasonable. Unless KM3 is some huge monster of a model whose generated code will bloat the byte code of the system significantly, generating the package/code for it is likely to result in a better performing and more compact instances even if only dynamic APIs are typically used.
I shall continue this discussion for a potentially wider audience under the "Is Ecore fit for MOF meta-modelling?" thread on the Modeling project newsgroup. There are some much wider philosophical issues.
I have made this contribution as part of Bug 145239. Once/if implemented you can just put something like <extension point="org.eclipse.emf.ecore.generated_package"> <resource uri = "http://www.eclipse.org/gmt/2005/KM3" model = "model/KM3.ecore" package = "KM3" /> <resource uri = "http://www.eclipse.org/gmt/2005/KM3Primitives" model = "model/KM3.ecore" package = "PrimitiveTypes" /> </extension> in plugin.xml. You might even be able to imitate org.eclipse.emf.ecore.xmi.impl.EMOF* to support use of *.km3 as a first class model representation.
