mtf/proposal.html

<h1>Modeling Team Framework (MTF)</h1>

<h2>Introduction</h2>
<p>Modeling Team Framework (MTF) is a proposed open source project under the <a
	href="http://www.eclipse.org/modeling/emft/">Eclipse Modeling
Framework Technology Project</a> (EMFT).</p>
<p>This proposal is in the Pre-Proposal Phase (as defined in the
<a href="http://www.eclipse.org/projects/dev_process/">Eclipse
Development Process document</a>) and is written to declare its intent and
scope. This proposal is written to solicit additional participation and
input from the Eclipse community. You are invited to comment on and/or
join the project. Please send all feedback to the <a
	href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.emft">http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.emft</a>
newsgroup.</p>
<h2>Background</h2>
<p>Many or nearly all modeling projects contain a lot of different
artifact types. Typically these are for example 
ecore based metamodels, EMF based models, other text sources 
like properties files or Java source files and also specific GMF or 
TMF based model editors. 
These editors are Eclipse plugins refering to specific metamodel versions.
The source files and EMF models must also be versioned with an SCM tool.
</p>
<p>
At most all files are under control of e.g. SVN, CVS or GIT.
But in this scenario EMF models are stored as normal file blobs, without 
the possibilities to show differences on EObject level.
On the other side repositories like CDO are great for storing EMF models 
but without special support for e.g. Java file based versioning and merging.
</p>
<p>
So one conventional solution is to have two projects in the Eclipse space. 
One for the EMF models and another for the other src files stored in e.g. SVN.
And on tasks like tagging or synchronizing, both repositories must be changed by hand.
</p>
<p>
The third artifact type, the editor plugins, are completely out of scope of the current
SCM tools. So the editor developer must install them by hand to a P2 repository or an Eclipse 
update site. 
For modeling the modeler must ensure to install the right version of the editor plugins
for the proper version of the metamodel according to the model, he/she likes to work on.
</p>
<p> 
The Modeling Team Framework will provide a mechanism like a meta repository on top of the
three repository types. It could be the base for software configuration management of 
Eclipse projects which uses the Eclipse Modeling Framework (EMF). 
The Modeling Team Framework will track the mapping between metamodel versions and editor plugins, 
and will automatically provide P2-based update sites.</p>
<p>
The basic ideas behind this meta modeling repository descended from the 
funded research project AMOR. See <a href="http://model-repository.org">model-repository.org (german only)</a> 
for further details.   
</p>
<h2>Scope</h2>
<p>The objectives of the Modeling Team Framework project are the following:</p>
<ul>
	<li>Define APIs and implement components based on EMF and the Eclipse Team API
	for storing, collaborating and synchronizing all software development artifacts 
	in modeling projects.</li>
	<li>Provide a UI for similar versioning handling of all these artifacts.</li>
	<li>Increase the usability of EMF-based modeling tools by
	simplifying the way, how editor plugins get loaded for specific metamodels.</li>
	<li>Integrate with other Eclipse components, e.g. CDO for storing/collaborating EMF models or 
	subclipse for storing text files in SVN repositories.</li>
	<li>Integrate with P2, to ease the way of Eclipse plugin updates.</li>
	<li>Provide a platform to collect and discuss requirements and use
	cases for versioning of modeling projects.</li>
</ul>
<p>Modeling Team Framework will not cover these issues:</p>
<ul>
	<li>Deal with models not based on EMF.</li>
	<li>Implement a model repository. MTF works as delegate only.</li>
	<li>Implement a source repository. MTF works as delegate only.</li>
	<li>Implement a P2 repository. MTF works as delegate only.</li>
</ul>
<h2>Description</h2>
<p>Modeling Team Framework will have to define APIs and provide implementations
for the following functionality:</p>
<dl>
	<dt>Team API</dt>
	<dd>The UI is built on top of the Team API from within Eclipse core.</dd>
	<dt>Collaboration</dt>
	<dd>The Team Server will provide collaboration and user session synchronization like CDO/Net4j or ECF.</dd>
	<dt>Persistence</dt>
	<dd>The Backend also stores e.g. plugins and textfiles in sync with metamodels stored in CDO. This information must 
	also persisted.</dd>
	<dt>Exchangeable storage backend for plugins and text files.</dt>
	<dd>The backend to actually store the different artifacts will be
	exchangeable, allowing customized implementations for specific storage
	technologies, such as pure SVN, CVS or others.
	</dd>
</dl>
<h3>Relationship with other Eclipse Projects</h3>
<ul>
	<li>Modeling Team Framework will be built on top of EMF.</li>
	<li>Modeling Team Framework will use CDO for storage of EMF models.</li>
	<li>Modeling Team Framework will provide a Team Server Adapter for Subclipse, CVSclipse or eGit.</li>
	<li>Modeling Team Framework will make contributions to Eclipse P2.</li>
	<li>The development Team will contribute necessary implementations and features to the used technologies like to CDO.</li>
	<li>The upcoming SOA Repository Framework in the SOA Tool Platform (STP), will make use of the Modeling Team Framework.</li>
</ul>
<h2>Organization</h2>
<h3>Mentors</h3>
<ul>
	<li>Ed Merks (Macro Modeling, Canada)</li>
	<li>Sven Efftinge (itemis AG, Germany)</li>
</ul>

<h3>Proposed initial committers</h3>
<ul>
	<li>Steffen Stundzig, itemis AG, project lead</li>
	<li>Sven Krause, Achievo Deutschland AG</li>
	<li>Helmar Behrends, Achievo Deutschland AG</li>
    <li>Steffen Dienst, Institute for Applied Informatics (InfAI) e.V.</li>
	<li>Robert Wloch, itemis AG</li>
	<li>Michael Willig, itemis AG</li>
</ul>

<h3>Interested parties</h3>
<p>The need for modeling project support has been discussed on 
several phone conferences, emails and local meetings in 2008 and 2009.</p>
<p>Parties indicating interest were</p>
<ul>
	<li>Achievo Deutschland AG, Sven Krause</li>
	<li>CDO Model Repository, Eike Stepper (CDO project lead)</li>
	<li>itemis AG, Sven Efftinge (TMF PMC)</li>
	<li>Oracle Deutschland GmbH, Berthold Maier</li>
	<li>Institute for Applied Informatics (InfAI) e.V., Stefan K&uuml;hne</li>
	<li>SOPERA GmbH, Zsolt Beothy-Elo</li>
    <li>Department of Business Information Systems at the University of Leipzig, Martin Gebauer</li>
	<li>flowr.org, Helmar Behrends</li>
	<li>Javier Mu&ntilde;oz, leader of the <a href="http://www.moskitt.org/eng/que-es-moskitt/">MOSKitt project</a></li>
	<li>Raphael Faudou, Atos Origin and the MDT Papyrus project</li>
	<li>Igor Burilo, Polarion Software (Subversive team)</li>
</ul>

<h3>Code contributions</h3>
<p>The initial code contribution will be a set of plug-ins from the
EPL based flowr.org project.</p>