Skip to main content

EMF Registry Proposal

Introduction

EMF Registry is a proposed open source project under the Eclipse Modeling Framework Technology Project (EMFT).

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.emft newsgroup.

Background

EMF provides a well-established and widely used mechanism to allow developers to publish model and meta-model as plugin registrations for use by Eclipse users.

There is no accepted mechanism to allow users to publish models and meta-models for use by themselves or other users. Consequently a modeling user developing for instance both a model transformation and a meta-model has no convenient way to enable tools processing the model transformation to locate the meta-model. Various modeling projects have worked around this problem with inconsistent and not very satisfactory solutions.

This problem was addressed in a modeling project independent fashion by the GMT UMLX Model Registry which migrated to the M2M QVT Declarative Model Registry. In order to support the migration of an OCL editor from M2M QVT Declarative to MDT OCL, a further migration of the Model Registry is necessary.

This proposal advocates making the Model Registry available as an independent project, facilitating its availability and usage in a modeling project independent fashion. An EMFT positioning makes this simple but critical modeling functionality available to all EMF users eliminating dependency problems. It avoids the need for a Model Registry migration to MDT OCL.

Description

A more detailed write-up may be found at http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/ModelRegistry.pdf

The model registry supports a two level user definable mapping. Firstly from an arbitrary name (such as UML_4_5) to a nominal URI (such as "http://one/day/uml4.5")~ and then from a nominal URI to an exact URI (such as platform://projects/MyUML/model/uml4_5.uml). Tool support for languages that define models using URIs can use the model registry as a URI resolver. Tool support for languages that define models using names may use both levels of mapping.

EMF Registry will provide the following functionality:

Persistent Registry
The Model Registrations are saved in a per-project EMF model.
Registry API
The API enables tools to browse the registry and locate and load a required (meta-)model.
UI - Registrations
Property pages support maintenance of the registry.
UI - Browser
A browser supports viewing registered models in a 'Sample Ecore Editor'.
Extensibility
Registration mechanisms will be extensible to support registration of a a variety of different model-related artefacts, such as transformations, execution engines, ...

EMF Registry will not provide the following functionality:

Persistent Models
EMF and other Eclipse Content Type related storage facilities are used.
Format conversion
The API will exploit existing Ecore/EMOF/UML conversions where available.
Transformation Compilation or Execution
Transformation language-dependent tools are enabled.
Transformation Sequencing
A problem too far for a 'simple' project..

Relationship with other Eclipse Projects

  • EMF Registry will be built on top of EMF.
  • As EMF Registry will be generic, it will be usable by any modeling project, not depending on the specific modeling language.
  • EMF/Index is expected to use EMF Registry to support location of the models and meta-models for which element indexing servicves are provided.
  • MDT/OCL will use EMF Registry to support location of meta-models for semantic validations and completions within, for instance, the OCL editor.
  • M2M/QVT Declarative will use EMF Registry to support location of meta-models for semantic validations and completions within, for instance, the QVT Relations and QVT Core editors and compilers.
  • M2M/QVT Operational is expected to use EMF Registry to support location of meta-models for semantic validations and completions within, for instance, the QVT Operational editors and compilers.
  • It is expected that the functionality of the M2M/QVT Operational model browser will be provided by the EMF Registry UI.
  • It is expected that the transformation registration functionality of the GMT/AM3 ATLAS MegaModel Management will be supported by the Model Registry allowing transformation composition tools to exploit accurate type signatures and transformation execution tools to invoke transformations in a variety of technologies.
  • GMT/UMLX will use EMF Registry to support location of meta-models for semantic validations and completions within, for instance, the UMLX editors.
  • It is expected that a variety of other modeling projects will benefit from this shared functionality.

Organization

Mentors

  • Sven Efftinge (itemis AG, Germany)
  • Cédric Brun (Obeo)

Proposed initial committers

  • Ed Willink (Thales, UK), lead

Interested parties

The M2M/QVT Declarative Model Registry and M2M/QVT Operational Model Browser were discussed at the Modeling BoF at the EclipseCon 2008.

Parties indicating interest are

  • AMMA, Jean Bézivin
  • Epsilon, Richard Paige
  • Topcased, Marc Pantel
  • Viatra, István Ráth

Code contributions

The initial code contribution will be a set of plug-ins from the M2M/QVT Declarative Eclipse project.

Back to the top