Skip to main content



  • 01 - What is the purpose of this Eclipse Modeling project?

    GMT acts as the research incubator of the Eclipse Modeling Project (EMP). It hosts a number of prototypes in the field of model engineering. These prototypes are named GMT components.

  • 02 - What is model engineering?

    Model engineering or Model Driven Engineering (MDE) is a generic acronym for several current trends in the field of software engineering, data engineering or system engineering. For a more precise definition of MDE you may refer to ""hyperlink"". The main idea is that many traditional tasks may be revisited by using models as a unifying paradigm.

  • 03 - What is the meaning of GMT?

    GMT stands for Generative Modeling Technologies.

    One of the most important operation in MDE is probably model transformation. This is the reason of the name of this project, even if it may target now more general operations on/about models.

  • 04 - There are several other Eclipse projects dealing with MDE. What is the specificity of GMT?

    MDE is far from being stabilized yet. It still needs a lot of exploratory work. GMT hosts a number of components usually produced by small companies or research groups. Each component is intended to help investigating some yet unexplored ideas/areas of MDE.

  • 05 - Is there some competition between GMT and other MDE projects like EMF, GEF, GMF, etc?

    There is more cooperation than competition between GMT and other MDE Eclipse projects. Most GMT components are based on facilities provided by these projects like EMF, GEF, GMF, etc. On some occasions GMT components may explore alternative ways to solve problems already solved by other projects, bringing new insight or focussing on other criteria. It is envisioned that some ideas put forward by GMT components may find their way to be integrated into more industry-oriented mature Eclipse MDE projects.

  • 06 - Is there competition between the GMT components themselves?

    If trying to find the best solution to some MDE problems is competition, then yes there is technical competition. For example GMT hosts several different solutions to perform model transformation. We see this as very positive. This does not come as a surprise. In the XML document transformation area there are also different solutions like XSLT or XQuery for different contexts. This existence of several transformation languages under GMT allows many possibilities like exchanging test cases and benchmarks, studying interoperability issues, building common librairies of transformation, etc. It is however an important objective of the project to achieve complementarity between the various GMT components. More precisely we hope to see new ways of solving classical practical problems with combinations of GMT tools.

  • 07 - Where can I find information on the prototype tools provided in GMT?

    Each component has its own documentation, hopefully including some kind of FAQ. Start from the GMT home page to find information on each project.

  • 08 - Our research group has been working on a stable prototype that will nicely complement the already available GMT contributions. How should we proceed to contribute this to the Eclipse GMT project?

    Just contact the GMT project leader. You may provide a text (pdf, word, etc.) of less than 5 pages with the following content:

    • a detailed description of your tool with some use cases and its history
    • a description of the code already available with sample screenshots showing the present maturity
    • a detailed plan of development showing how a community of users may build up around the tool

  • 09 - I am interested in contributing to a component already present in GMT. How should I proceed?

    If you know the Eclipse GMT committer in charge of this tool, contact this committer directly. You may also ask the GMT project leader. But the recommended way is to post a public message on the newsgroup of the component. In case the component has no open newsgroup, just post over the GMT newsgroup.

  • 10 - I am a user of a GMT tool and I would like to share my experience and to contribute some application data. Is this possible?

    You are really welcome doing this. For example if you developed some transformations in one of the languages supported by GMT tools, then you are more than welcome to contribute your code to the project. Your code may help other start using the tool. It may also contribute to the set up of much needed librairies of reusable components.

    Here again posting public message on the various newsgroups is highly recommended.

  • 11 - How will GMT tools cooperate?

    They are using some standard formats like Ecore, XMI 2.0, XMI 2.1, etc. They also share the same philosophy of considering models as first class entities.

    Being transformation-based, this project naturally facilitates integration because a lot of technological bridges are available to cope with a set of different formats.

  • 12 - Does this mean that we may also use non XMI-encoded data in GMT tools like native text-based Java code, plain XML, SQL code, etc.

    Yes, some tools may accept these formats. After all the proposition of real-life data natively encoded in XMI is very low.

  • 13 - Can we say that GMT is UML-centric?

    UML is a general purpose modeling language. The philosophy behind GMT is rather to follow the DSL path. A DSL (Domain Specific Language) is usually smaller and more focused on some specific goal or problem area. MOF and Ecore are powerful generic tools to define DSLs. Other facilities present in EMP facilitate the management of a variety of DSLs. For example GMF adresses the need to define graphical syntaxes for DSLs.

    Not being UML-centric does not mean that GMT tools are not able to deal with UML models. In particular these tools may interface with most of currently available UML CASE tools.

  • 14 - What are the basic artifacts in GMT?

    The basic entities are metamodels. A metamodel may be a standard one like UML 2.0, CWM 2.0, SPEM 2.0, etc. You may also roll your own metamodel in the fields of business engineering, system engineering, data engineering, software engineering.

  • 15 - What are the formats for encoding metamodels?

    GMT metamodels are naturally expressed in Ecore. The most known exchange formats are the various versions of XMI. Currently (2006) the recommended format is XMI 2.1 but it is not yet implemented by many tools. Other alternative formats already exists like Emfatic and KM3.

  • 16 - I would like to define myself a metamodel. How should I proceed?

    There are several solutions. One of them is to use a UML CASE tool and to write a class diagram. From the resulting XMI code of this UML class diagram model, you need to produce the XMI code for your metamodel. The operation consisting in transforming a UML model into a MOF metamodel is called a promotion. You may find tools that may implement this operation. One of them is UML2MOF available under the MDR/Netbeans environment. Alternatively you may also write your metamodel in a syntax like Emfatic or KM3. To do this just use your preferred text editor (Emacs, etc.).

  • 17 - What is the lifecycle of a GMT component?

    The lifecycle of a component starts by its acceptance as described. When this is achieved, usually one major committer is in charge of the component and it is improved and updated by the community (for example by a Bugzilla-based process). The component usually attracts a user community that helps improving it by public discussions and contributions.

    It may happen at some time that a GMT component has attracted a wide user community and is quite stable. Then it is possible that this component may leave GMT to become a separate modeling project or to participate to another modeling project. This is a success situation for the component. It also a success for GMT that has hosted a research prototype to the point that it is sufficiently mature to become a stable industrial solutions.

    In some other cases a GMT component may also become inactive by lack of users or contributors. This component will then be archived. This is not a failure because, during its lifecycle, the component may have influenced the evolution of MDE practices. As a research incubator GMT may take more risks than other modeling projects because research mean also investigating innovative, unexplored and risky paths.

Topics list

Back to the top