Skip to main content

EMF Client Platform (ECP)

EMF Client Platform (ECP)

The EMF Client Platform (ECP) project is a proposed open source project under the EMFT Container Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the Eclipse community. Please send all feedback to the EMFT forum.

Background

The Eclipse Modeling Framework (EMF) allows model-driven development of entity centric applications built around a EMF model. Typical applications follow a common template. They provide a tree-based view for navigation, a detailed editor for one entity of the model and a number of additional customized views. Additionally the entities have to be persisted, versioned and shared among multiple clients. Such applications usually require the use of several frameworks additional to EMF such as JFace, Eclipse Data-binding, CDO or GMF. Some of these frameworks offer explicit support for EMF such as Data-binding or are already EMF-centric such as GMF. However many frameworks such as JFace, the standard Validation View, or the Resources framework offer more generality and are not tailored to EMF. Even though those frameworks significantly reduce the effort of building entity-centric applications it is still a long way from an EMF model to a running application fulfilling basic requirements. This is especially true for developers inexperienced with Eclipse technology. They have to overcome a high entry barrier as they have to evaluate, select and comprehend a variety of existing frameworks and their interplay. Therefore the goal of the EMF Client Platform is to provide a one-click start to the creation of an entity-centric EMF application. The resulting standard application is based on a selection of existing frameworks and already delivers basic features. It can be refined and adapted step by step.

Scope

The objectives of ECP are the following:
  • Provide a one-click entity-centric application based on EMF. All components are customizable and replaceable
  • Provide a reflective UI for arbitrary EMF instances including a navigator, an editor and a validation view
  • Provide a transparent model workspace including persistency and versioning
  • Provide EMF-based APIs
  • Provide EMF-based adapters to existing framework such as GMF or Drag and Drop
The following Manifest details the scope of the ECP project:

Manifest

One-click Application

The goal of ECP is to provide an entity-centric client application based on an EMF model. The only initial step required to create an application is to generate the model itself. All additional components are either generic or adapted reflectively. ECP provides a reflective UI for entity-centric applications. This includes a tree-based navigator, a form-based editor for single entities and a view for EMF validation results. These UI elements do not have to be generated, but work with an EMF model from scratch. Furthermore ECP provides a transparent model workspace to store models in. The developer has not to deal with files or resources, but can access any EObject using EMF-based APIs. The models in a workspace can be shared among different clients by relying on a model repository.

Extensible and Replaceable

ECP provides a one-click standard application. This solution masks the complexity of choosing and adapting existing frameworks. However a framework can not provide a final solution for all use cases. Consequently every component such as the reflective editor of ECP is customizable by extension points. Furthermore every component is also completely replaceable by customized solutions. This facilitates a fast development start-up where the full application is still a default ECP-based application, but still allows to evolve the application to a fully-customized product.

EMF-Centric

ECP is EMF centric. No component is required to work without EMF. Consequently ECP enables the developer to work with EObjects (EMF Objects) instead of Java Objects. All interfaces provide EObjects. To leverage existing Eclipse technologies, ECP provides adapters to existing frameworks hiding their generality and therefore avoid unnecessary complexity and casts.

Initial Contribution

Several components of the proposed ECP have already been developed as part of the existing UNICASE project. The components to be contributed are:

Model Workspace

The model workspace provides transparent persistency for EObjects. They can be accesses based on an EObject "Project" providing a EMF based API. This includes methods such as getAllEObjectsByClass(EClass). Since persistency is transparent in the workspace, the developer does not have to deal with resources or files. The provided default persistency layer distributes EObjects included in a project dynamically over several XML files for improved performance. This solution can be replaced, for example with a data base persistency layer based on Teneo. The workspace also allows to integrate a model repository. Currently the workspace integrates the existing EMFStore repository. We plan to integrate other repositories such as CDO by using the Modeling Team Framework. Additionally the model workspace provides integrated support to migrate existing model instances in case the underlying EMF model has been changed. This is based on EDAPT.

Model Navigator

The Navigator provides a tree-based view using the EMF-based API of the workspace. It provides standard actions for creating deleting and moving EObjects. In contrast to the standard solution based on EMF.edit, it provides a tree-based and structured creation dialog. This dialog can be used, if an EObject instead of simple displaying all possible child type of an EObject in the right click menu. This is useful if an EObject has a large number of possible child types.

Model Editor

The Model Editor is a reflective form-based editor to modify a single entity. It is based on JFace. The editor can open a single EObject. It reflectively shows all attributes and references of the EObject. The idea is similar to the existing properties view, but the Editor is form-based and provides custom widgets, for example to display multi-line attributes. Reference widgets offer dialogs to search for new reference EObjects and also to create them. New widgets can be added and existing widgets can be replaced via extension points. For example the writers attribute of the library EObject (EMF Library example) could be replaced by a list including images of the authors.

Model Validation View

EMF can validate a model instance by defined constraints. Eclipse provides a standard view to display the result of the validation. This view is not model based, but relies on resources. ECP provides a EMF specific validation view, which can be filtered based on the model. A constraint violation is depending on a certain EObject. This EObject can be directly opened in the ECP Model Editor. The Editor highlights attributes, which cause violations. Furthermore the validation view defining fixes (e.g. refactorings) to solve specific validation violations. Validation rules, fixes and filters can be registered via extension points.

Model Commons

Models Commons provides generic functionality of ECP. All other plugins are depending on commons. Double click actions on a certain EObject can be registered via extension point. As default action common will open the ECP Editor. A user can search and open EObjects in dialog similar to "Open Type" in the JDT. For Drag and Drop common provides an extension point offering an EMF-based interface to register custom drop actions. GMF diagrams require files to be opened. Common provides a virtual resource for GMF. This allows opening diagrams using a EMF based interface. Additionally common provides many small but useful adapters, e.g. to retrieve a currently selected EObject.

Relationship with other Eclipse Projects

  • ECP builts on top of EMF and EMF Edit
  • ECP uses the EMF Validation Framework
  • ECP uses Databinding
  • ECP uses Nebula Widgets
  • ECP adapts GMF with a model-based API
  • ECP plans to use the Model Team Framework

Organization

Initial committers

  • Jonas Helming (Technische Universität München, Germany) - proposed project co-lead
  • Maximilian Koegel (Technische Universität München, Germany) - proposed project co-lead
  • Nitesh Narayan (Technische Universität München, Germany)
  • Alexandar Shterev (Independant Developer)
  • Otto Wesendonk (Independant Developer)
  • Florian Pirchner (RedView)
  • Eike Stepper (ES Computersysteme)

Interested parties

  • EDAPT
  • RedView
  • Bauhaus Luftfahrt
  • Beople GmbH
  • Max Planck Institute Munich
  • SEISSOL
  • Hallvard Trætteberg
  • Chair of Prof. Paech, Universität Heidelberg
  • Chair of Prof. Buersner, Universität Bonn

Mentors

  • Ed Merks (Macro Modeling, Canada)
  • Tom Schindl (BestSolution.at)

Changes to this Document

Date Change
25-March-2010 Document created

Back to the top