blob: 99c316e70327751a741474bf4ee5ac3e41d79f2b [file] [log] [blame]
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:
Direct any questions about this template to
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>
<p>The EMF Client Platform (ECP) project is a proposed open source
project under the <a
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="">EMFT forum</a>.</p>
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.
The objectives of ECP are the following:
<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>
The following Manifest details the scope of the ECP project:
<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.
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
<h3>Model Workspace</h3>
The model workspace provides transparent persistency for EObjects. They
can be accesses based on an EObject &quot;Project&quot; 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
&quot;Open Type&quot; 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>
<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>
<h3>Initial committers</h3>
<li>Jonas Helming (Technische Universit&auml;t M&uuml;nchen,
Germany) - proposed project co-lead</li>
<li>Maximilian Koegel (Technische Universit&auml;t M&uuml;nchen,
Germany) - proposed project co-lead</li>
<li>Nitesh Narayan (Technische Universit&auml;t M&uuml;nchen,
<li>Alexandar Shterev (Independant Developer)</li>
<li>Otto Wesendonk (Independant Developer)</li>
<li>Florian Pirchner (RedView)</li>
<li>Eike Stepper (ES Computersysteme)</li>
<h3>Interested parties</h3>
<li>Bauhaus Luftfahrt</li>
<li>Beople GmbH</li>
<li>Max Planck Institute Munich</li>
<li>Hallvard Tr&aelig;tteberg</li>
<li>Chair of Prof. Paech, Universit&auml;t Heidelberg</li>
<li>Chair of Prof. Buersner, Universit&auml;t Bonn</li>
<li>Ed Merks (Macro Modeling, Canada)</li>
<li>Tom Schindl (</li>
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.
<td>Document created</td>