EMF Developer FAQ
frequently asked question and answers

EMF Developer FAQ
Last Modified: September 24th, 2002

Table of contents:
General Goto Toptop
  1. What is EMF?

    The Eclipse Modeling Framework is a Java/XML framework for generating tools and other applications based on simple class models. EMF helps you rapidly turn models into efficient, correct, and easily customizable Java code. It is intended to provide the benefits of formal modeling, but with a very low cost of entry. In addition to code generation, it provides the ability to save objects as XML documents for interchange with other tools and applications. Models can be created using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. The code generator turns a model into a set of Java implementation classes. These classes are extensible and regenerable - you can modify them by adding user-defined methods and instance variables. When the model changes, you can regenerate the implementation classes, and your modifications will be retained. This works both ways - changes in the Java code can be used to update the model.

  2. How do I get started with EMF?

    Start by reading the overview documents and the tutorial, followed by downloading the driver.

  3. What exactly is the tutorial trying to show?

    After going through the tutorial, you will have generated a completely working editor from nothing but a picture of the object model (i.e., the simple libarary model shown in the tutorial). If you run the generated editor, you can add and remove books and authors, edit the properties (e.g., the book title), copy, paste, drag-and-drop, etc. All with unlimited undo/redo. You can also save the document (the default framework serialization format is XMI).

    The purpose of the tutorial is to illustrate the power of a model driven architecture (MDA). By providing a model for the data your application will manipulate, you can use EMF to generate a Java implementation for you. EMF.Edit can leverage the same model (meta) data to generate view support and even a working editor. Read the overview documents for more details.

  4. Are there any "real" example EMF models in Eclipse?

    Well, for starters, EMF itself contains two interesting models. The Ecore model serves as the meta-model for any EMF model you create -- it is the model that describes the structure of your models. The Genmodel controls generation of an EMF model. In fact, the generator UI that is used in the tutorial is the EMF.Edit editor for the Genmodel, which explains why it looks so much like the library editor in the tutorial. If you want to explore Ecore and Genmodel further, you'll find their Rose models and Java code in the EMF source package available on our download page. Of course, the code produced by the EMF generator is meant to be a starting place, so you'll see that much functionality has been manually added to both of these models. But, it's quite easy to see the same sort of generated patterns that appear in the simple library example. Ecore is in the org.eclipse.emf.ecore plugin, the Genmodel is in org.eclipse.emf.codegen.ecore, and its editor UI is in org.eclipse.emf.codegen.ecore.ui. You'll find the Rose models in the "model" subdirectory of the source for the former two plugins.

    Finally, an even more complex example of an EMF model is XSD, the XML Schema Infoset Model, a subproject of the Eclipse Technology Project. XSD models the concrete and abstract relationships expressed in an XML schema document, providing an API to manipulate the model and an XML-schema-specific replacement for EMF's default XMI serialization. Of course, there's also an EMF.Edit-based XML schema editor built on it.

Download and Install Goto Toptop
  1. How do I Install EMF?

    Download the version of EMF that matches your installation of Eclipse.  Exit Eclipse, and Unzip into the eclipse directory.

Modeling Standards Goto Toptop
  1. What is the relationship of OMG™ MOF™ to the EMF Ecore model?

    The OMG MOF 1.4 Model has influenced the design of the EMF Ecore model. The Ecore model evolved in parallel with the MOF 1.4 model. Implementation experience in integrating a number of tools led to an optimized implementation (focused on tool integration as opposed to the original MOF focus of metadata repositories) that uses a subset of the modeling concepts in MOF 1.4. For example, Ecore does not support ‘first class’ Associations. Associations are mapped to a pair of Ecore References. To minimize confusion, we have used the term ‘Ecore’ to refer to the object model in the EMF framework. We use the terms ‘Ecore model’ and ‘EMF model’ interchangeably in this FAQ, because the object model of the Eclipse EMF framework is the Ecore model.

    The designers of EMF are participating in the OMG process to influence the design of MOF 2.0 and UML 2.0, which are still being defined.

  2. Does EMF support OMG XMI?

    EMF uses OMG XML Metadata Interchange (XMI™) 2.0 as the default XML serialization format for Ecore models and Ecore instances. The EMF framework allows the use of other serialization formats also. The XMI 2.0 document production rules are used because of more compact representation than XMI 1.2.

  3. Can I create an EMF model using UML™ modeling tools?

    EMF models can be defined using UML modeling tools such as Rational Rose. You simply define a class model with the packages, attributes, references, data types, and operations. This class model can be imported into EMF for additional code generation. Since many Java developers are familiar with simple class modeling, this serves as a ‘gentle introduction’ to UML class modeling. In addition to UML class models, EMF models can be created by using annotated Java interfaces or by directly editing an XMI document using an XML editor. This approach is used to allow the benefits of model based code generation (one of the principles of the OMG Model Driven Architecture – MDA) to not just users familiar with UML, but also the larger community of developers using Java and XML.

  4. Can I create an EMF model using OMG XMI?

    Yes. The XMI document that conforms to the EMF Ecore model can be directly edited using your favorite text or an XML editor. Alternately you can use a modeling tool that can produce the XMI document from a UML model. You can also use annotated Java interfaces to define your input model.

  5. What is Model Driven Architecture – MDA?

    MDA is an industry architecture proposed by the OMG that addresses full life cycle application development, data, and application integration standards that work with multiple middleware (CORBA, J2EE), languages, and interchange formats. MDA unifies some of the industry best practices in software architecture, modeling, metadata management, and software transformation technologies that allow a user to develop a modeling specification once and target multiple technology implementations by using precise transformations/mappings.

    An example of the use of MDA is to use a UML model representation of a tool or application and to use this model to automate (some or all) of the Java interface, implementation, as well as any XML serialization for the modeled objects. Many of the recent OMG standards such as UML, MOF, and CWM were developed using MDA principles of using abstract models (these are also referred to as Platform Independent Models – PIM) which can be mapped to Platform Specific Models (PSM). Please note that ‘platform independent’ is a relative term!

    For more information on MDA and related MDA specifications including UML, XMI, and MOF, please visit www.omg.org/mda.

  6. What is the relationship of EMF to OMG™ MDA™?

    One of the key goals of EMF is to use simple visual models to allow easy integration of Java and XML tools. To accomplish this you can use a UML class model as input to the EMF framework. This model is then used to drive Java interface and implementation generation for EMF instances. These Java interfaces define a consistent programming model for tools built using EMF. The same EMF model is also used to generate the XML serialization (XMI 2.0 format) for EMF instances. Essentially EMF supports the key MDA concept of using models as input to development and integration tools which produce multiple programming language (Java in the case of Eclipse EMF itself) or data interchange format (XML) representations. The code generation and XML serialization is ‘driven’ from the same model.

    EMF supports OMG XMI 2.0 XML serialization format and the use of UML models for the analysis and design of EMF models.

  7. What is the relationship of EMF to JMI™?

    JMI (Java™ Metadata Interface) is a mapping of the OMG MOF 1.4 to the Java language developed by the Java Community Process. The JMI spec and the Eclipse EMF model to Java mapping were developed in parallel and are not the same. The Eclipse EMF Java mappings have been optimized for in memory tool integration using Java and XML while JMI has been optimized for metadata repository usage scenarios. Eclipse EMF designers are actively involved in the ongoing development of MOF 2.0 and related mappings to XML and Java that are expected to proceed in the OMG and Java Community Process respectively.

Developer Goto Toptop
  1. Does it matter what node in the genmodel tree I invoke Generate from?

    Definitely. To do a full generation, you need to invoke "Generate" or "Generate EMF.Edit" from the root node in the genmodel editor. If you invoke Generate lower down, you'll only generate the files associated with the selected subtree.

  2. Can model classes be in the Java default package?

    No. EMF does not allow model classes to be in the default Java package because it would need to be handled specially in the code generator, and since it's not a good Java convention anyway, we don't think it is worth supporting. Make sure that if you load your model from annotated Java that all the interfaces and classes with an @model tag also have an explicit package declaration.

  3. Can annotated Java files use * imports?

    Currently no. Until our Java name lookup mechanisms are improved, we really rely on explicit imports to resolve names, i.e., two * imports would confuse the code. It's best to entirely avoid * imports for the time being. We will improve identifier lookup in the coming weeks.

  4. Does regeneration/merge work for properties and plugin.xml files?

    Not yet. The current generator does not support merge for the plugin.properties and plugin.xml files, so it will not overwrite them if they exist. If you want to regenerate them, you'll need to remove or rename them before regenerating. This will also be improved in the future.

  5. Can EMF be used in stand-alone applications?

    An EMF model can be used without change in a stand-alone application with one exception. The default (XMI) serializer is not registered in the stand-alone EMF environment, so you need to explicitly register it with your model. For example, to register the XMI serializer for the library model, you would add something like this in your main:

       Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("library", new XMIResourceFactoryImpl());
    

    For EMF.Edit, the following framework plugins contain resources.jar files that need to be on the CLASSPATH for stand-alone execution.

    1. org.eclipse.emf.common.ui/runtime/common.ui.resources.jar
    2. org.eclipse.emf.common/runtime/common.resources.jar
    3. org.eclipse.emf.edit.ui/runtime/edit.ui.resources.jar
    4. org.eclipse.emf.edit/runtime/edit.resources.jar

    Also, to produce the right .jar file for stand-alone execution of a generated project, you need to copy the plugin.properties file and the icons directory to the directory containing the EMF XyzPlugin for the project. This will put the resources in just the right place to be found by the generated XyzPlugin during stand-alone execution. Such a project will work as both a plugin and for stand-alone execution.