| <!-- |
| This document is provided as a template along with some guidance for creating |
| your project proposal. This is just a template. Feel free to change it as |
| you see fit (add sections, remove section). We feel, however, that the |
| suggestions represented in this document represent the reasonable minimum |
| amount of information to move forward. |
| |
| Please keep the formatting in this document simple. Please do not edit |
| this document in Microsoft Word as it adds huge piles of markup that make |
| it difficult to restyle. |
| |
| More information is available here: |
| |
| http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase |
| |
| Direct any questions about this template to emo@eclipse.org |
| --> |
| |
| <html> |
| <head> |
| |
| <!-- |
| Include the title here. We will parse it out of here and include it on the |
| rendered webpage. Do not duplicate the title within the text of your page. |
| --> |
| |
| <title>EMF Client Platform (ECP)</title> |
| </head> |
| |
| <body> |
| <p>The EMF Client Platform (ECP) project is a proposed open source |
| project under the <a |
| href="http://www.eclipse.org/projects/project_summary.php?projectid=modeling.emft">EMFT |
| Container Project</a>.</p> |
| |
| <p>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 <a |
| href="http://www.eclipse.org/forums/eclipse.technology.emft">EMFT forum</a>.</p> |
| |
| <h2>Background</h2> |
| |
| 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. |
| |
| |
| <h2>Scope</h2> |
| The objectives of ECP are the following: |
| <ul> |
| <li>Provide a one-click entity-centric application based on EMF. |
| All components are customizable and replaceable</li> |
| <li>Provide a reflective UI for arbitrary EMF instances including |
| a navigator, an editor and a validation view</li> |
| <li>Provide a transparent model workspace including persistency |
| and versioning</li> |
| <li>Provide EMF-based APIs</li> |
| <li>Provide EMF-based adapters to existing framework such as GMF |
| or Drag and Drop</li> |
| |
| </ul> |
| |
| The following Manifest details the scope of the ECP project: |
| <h2>Manifest</h2> |
| <h3>One-click Application</h3> |
| 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. |
| <h3>Extensible and Replaceable</h3> |
| 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. |
| <h3>EMF-Centric</h3> |
| 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. |
| |
| |
| <h2>Initial Contribution</h2> |
| |
| Several components of the proposed ECP have already been developed as |
| part of the existing UNICASE project. The components to be contributed |
| are: |
| <h3>Model Workspace</h3> |
| 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. |
| <h3>Model Navigator</h3> |
| 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. |
| <h3>Model Editor</h3> |
| 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. |
| <h3>Model Validation View</h3> |
| 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. |
| <h3>Model Commons</h3> |
| 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. |
| |
| <h2>Relationship with other Eclipse Projects</h2> |
| <ul> |
| <li>ECP builts on top of EMF and EMF Edit</li> |
| <li>ECP uses the EMF Validation Framework</li> |
| <li>ECP uses Databinding</li> |
| <li>ECP uses Nebula Widgets</li> |
| <li>ECP adapts GMF with a model-based API</li> |
| <li>ECP plans to use the Model Team Framework</li> |
| </ul> |
| <h2>Organization</h2> |
| <h3>Initial committers</h3> |
| <ul> |
| <li>Jonas Helming (Technische Universität München, |
| Germany) - proposed project co-lead</li> |
| <li>Maximilian Koegel (Technische Universität München, |
| Germany) - proposed project co-lead</li> |
| <li>Nitesh Narayan (Technische Universität München, |
| Germany)</li> |
| <li>Alexandar Shterev (Independant Developer)</li> |
| <li>Otto Wesendonk (Independant Developer)</li> |
| <li>Florian Pirchner (RedView)</li> |
| <li>Eike Stepper (ES Computersysteme)</li> |
| </ul> |
| |
| <h3>Interested parties</h3> |
| <ul> |
| <li>EDAPT</li> |
| <li>RedView</li> |
| <li>Bauhaus Luftfahrt</li> |
| <li>Beople GmbH</li> |
| <li>Max Planck Institute Munich</li> |
| <li>SEISSOL</li> |
| <li>Hallvard Trætteberg</li> |
| <li>Chair of Prof. Paech, Universität Heidelberg</li> |
| <li>Chair of Prof. Buersner, Universität Bonn</li> |
| </ul> |
| <h3>Mentors</h3> |
| <ul> |
| <li>Ed Merks (Macro Modeling, Canada)</li> |
| <li>Tom Schindl (BestSolution.at)</li> |
| </ul> |
| |
| <!-- |
| New Eclipse projects require a minimum of two mentors from the Architecture |
| Council. You need to identify two mentors before the project is created. The |
| proposal can be posted before this section is filled in (it's a little easier |
| to find a mentor when the proposal itself is public). |
| --> |
| |
| |
| |
| <h2>Changes to this Document</h2> |
| |
| <!-- |
| List any changes that have occurred in the document here. |
| You only need to document changes that have occurred after the document |
| has been posted live for the community to view and comment. |
| --> |
| |
| <table> |
| <tr> |
| <th>Date</th> |
| <th>Change</th> |
| </tr> |
| <tr> |
| <td>25-March-2010</td> |
| <td>Document created</td> |
| </tr> |
| </table> |
| </body> |
| </html> |