emf-client/proposal.html - www.eclipse.org/proposals - Git at Google

 <!--
 	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 &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>
 <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&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,
 	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&aelig;tteberg</li>
 	<li>Chair of Prof. Paech, Universit&auml;t Heidelberg</li>
 	<li>Chair of Prof. Buersner, Universit&auml;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>
	<!--
	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>