ebm/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>
 <title>

 <!--
 	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.
  -->

 EMF Build Manager
 </title>

 <body>
 <p>EBM - short for EMF Build Manager - is a proposed project under the <a href="http://www.eclipse.org/modeling/emft">Eclipse Modeling Framework Technology project</a>.
 </p>
 <p>This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) 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/forums/eclipse.technology.emft">EMFT forum</a> with "[EBM]" in the subject.
 </p>
 <h2>Background</h2>

 <p>EMF has been around for a long time. But the fact is that it lacked the necessary IDE Build Manager integration ever since.
 </p><p>We think, the current code generation and validation toolset is below eclipse UI quality standards and fell behind similar facility provisions from the other projects.
 </p><p>For instance, given the current infrastructure, if a developer is working with two ecore models that are dependent each other along with their respective genmodel, when developer makes a change in the base model that requires a change in the dependent ecore model, will need quite a lot of
 clicks and at least 4 editor switches, 2 actions executions along with several clicks to locate the action and run them.
 </p><p>Also during the generation process, the UI is blocked and having finished the change on the base ecore, the developer cannot continue working on the second ecore before the base model generation finishes. Further more there is also need to switch to genmodels twice and initiate generation delibarately.
 </p><p>In addition to this, if developer would like to validate the model in between the unit of the works, that will require clicks to locate the validation action, click to run the action and click to dismiss the feedback.
 </p><p>It is also in our experience that the genmodel editors are kept open just for triggering code genration. Furthermore, this not only clutters the editor folder with unneeded editors, but also breaks the 'editor' description for genmodel, as usualy once genmodels are set up, they very seldom
 change, but needed to be open for code generation. When used on large workspaces with more than a few model, problem becomes a real burden. This is where EBM steps in and delegates much of the work to background build manager and prevents user distrubition with using the instruments like auto build on resource save, Marker and Problem View instrumentation to provide feedback.
 </p>

 <h2>Vision</h2>
 <p>Project has the following vision:
 </p>
 <ul><li> Provide the backgound instrumantation to remove the burden from the UI
 </li><li> Eventually merge with the mother project and retire the current editor based instrumentation
 </li><li> Provide extension points downstream model driven development to integrate (ie: GMF for model validation and generation)
 </li></ul>

 <h2>Prerequisites</h2>
 <p>All the framework requirements currently satisfied at the required level by EMF Core. This includes:
 </p>
 <ul><li> Validation framework decoupled from the UI
 </li><li> Code generation framework decoupled from the UI

 </li><li> Workspace modification prevention in between the changes
 </li><li> Marker support to provide feedback for model and code generation status
 </li></ul>
 <h2>Scope</h2>
 <p>The objectives of the EBM project are to:
 </p>
 <ul><li> Provide a nature implementation for EMF based projects.
 </li><li> Provide a builder for EMF based projects that will validate (ecore, genmodel, xmi) resources and will (re)generate the EMF based resources

 </li><li> Will introduce dependencies across model resources based on EMF resource cross links and will trigger further builds on affected models.
 </li><li> Provide an extension point for downstream model developer's implementations to integrate with the build system.
 </li><li> To replace the UI triggered code generation and validation of EMF resources eventually.
 </li></ul>

 <h2>Description</h2>
 <p>The prototype code base is at the alpha stage and considered to be ready for development build testers. The initial idea is to gather community on the eclipse website and newgroups to adopt tester. Primary goal is to have the project be release along with Helios Simultaneous Release
 </p>

 <h2>Organization</h2>

 <p><b>Mentors</b></p>


 <p><b>Initial committers</b>
 </p><p>The initial committers will focus on providing ease of use to those who work with more then a few models on their everyday work. Our agile development process will follow eclipse.org's standards for openness and transparency.  Our goal is to provide the infrastructure and APIs and
 documentation needed to integrate downstream model developer's models with the building infrastructure and provide timely support on a dedicated eclipse newsgroup or within EMF newsgroup.
 </p><p>The initial committer is:
 <i>Hasan Ceylan</i> (batoo.org), has known to submit patches to a few eclipse projects, namely Platform, EMF DataBinding, Teneo, CDO, RAP, TMF/Xtend/Xpand, XWT, GEF, GMF, etc.
 </p><p><br>
 <b>Developer community</b>
 </p><p>As the context is limited we do not anticipate a significant interest in becoming contrubitor on the project.
 </p><p><br>
 <b>User community</b>
 </p><p>Project will try to collect ideas to improve and enhance the build process using EMF newgroup and eclipse.org provided bugzilla.
 </p><p><br>
 <b>Tentative Plan</b>

 </p><p><i>2010-02-08 v0.1.beta</i>
 milestone release with ECORE, XMI, GENMODEL validation and generation and limited dependency management. RELEASED
 </p><p><i>2010-03-06 v0.1.release</i>
 production release with full supportto ECORE, XMI, GENMODEL validation and generation and dependency management.
 </p><p><i>2010-03-19 v0.2.beta</i>
 milestone release with support for downstream model registration
 </p><p><i>2010-04-15 v0.2.beta</i>
 milestone release 1 with support for community requested enhancements
 </p><p><i>2010-05-07 v0.3.beta</i>
 milestone release 2 with support for community requested enhancements
 </p><p><i>2010-05-21 v1.0RC1</i>

 release candidate 1
 </p><p><i>2010-05-28 v1.0RC2</i>
 release candidate 2
 </p><p><i>2010-06-04 v1.0RC3</i>: release candidate 3
 </p><p><i>2010-06-11 v1.0RC3</i>: release candidate 4
 </p><p><i>2010-06-23 v1.0</i>: public release
 </p><p><i> +Helios Plan</i> is to migrate the project into EMF Core
 </p>
 <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>DD-Month-YYYY</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>
	<title>

	<!--
	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.
	-->

	EMF Build Manager
	</title>

	<body>
	<p>EBM - short for EMF Build Manager - is a proposed project under the <a href="http://www.eclipse.org/modeling/emft">Eclipse Modeling Framework Technology project</a>.
	</p>
	<p>This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) 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/forums/eclipse.technology.emft">EMFT forum</a> with "[EBM]" in the subject.
	</p>
	<h2>Background</h2>

	<p>EMF has been around for a long time. But the fact is that it lacked the necessary IDE Build Manager integration ever since.
	</p><p>We think, the current code generation and validation toolset is below eclipse UI quality standards and fell behind similar facility provisions from the other projects.
	</p><p>For instance, given the current infrastructure, if a developer is working with two ecore models that are dependent each other along with their respective genmodel, when developer makes a change in the base model that requires a change in the dependent ecore model, will need quite a lot of
	clicks and at least 4 editor switches, 2 actions executions along with several clicks to locate the action and run them.
	</p><p>Also during the generation process, the UI is blocked and having finished the change on the base ecore, the developer cannot continue working on the second ecore before the base model generation finishes. Further more there is also need to switch to genmodels twice and initiate generation delibarately.
	</p><p>In addition to this, if developer would like to validate the model in between the unit of the works, that will require clicks to locate the validation action, click to run the action and click to dismiss the feedback.
	</p><p>It is also in our experience that the genmodel editors are kept open just for triggering code genration. Furthermore, this not only clutters the editor folder with unneeded editors, but also breaks the 'editor' description for genmodel, as usualy once genmodels are set up, they very seldom
	change, but needed to be open for code generation. When used on large workspaces with more than a few model, problem becomes a real burden. This is where EBM steps in and delegates much of the work to background build manager and prevents user distrubition with using the instruments like auto build on resource save, Marker and Problem View instrumentation to provide feedback.
	</p>

	<h2>Vision</h2>
	<p>Project has the following vision:
	</p>
	<ul><li> Provide the backgound instrumantation to remove the burden from the UI
	</li><li> Eventually merge with the mother project and retire the current editor based instrumentation
	</li><li> Provide extension points downstream model driven development to integrate (ie: GMF for model validation and generation)
	</li></ul>

	<h2>Prerequisites</h2>
	<p>All the framework requirements currently satisfied at the required level by EMF Core. This includes:
	</p>
	<ul><li> Validation framework decoupled from the UI
	</li><li> Code generation framework decoupled from the UI

	</li><li> Workspace modification prevention in between the changes
	</li><li> Marker support to provide feedback for model and code generation status
	</li></ul>
	<h2>Scope</h2>
	<p>The objectives of the EBM project are to:
	</p>
	<ul><li> Provide a nature implementation for EMF based projects.
	</li><li> Provide a builder for EMF based projects that will validate (ecore, genmodel, xmi) resources and will (re)generate the EMF based resources

	</li><li> Will introduce dependencies across model resources based on EMF resource cross links and will trigger further builds on affected models.
	</li><li> Provide an extension point for downstream model developer's implementations to integrate with the build system.
	</li><li> To replace the UI triggered code generation and validation of EMF resources eventually.
	</li></ul>

	<h2>Description</h2>
	<p>The prototype code base is at the alpha stage and considered to be ready for development build testers. The initial idea is to gather community on the eclipse website and newgroups to adopt tester. Primary goal is to have the project be release along with Helios Simultaneous Release
	</p>

	<h2>Organization</h2>

	<p><b>Mentors</b></p>


	<p><b>Initial committers</b>
	</p><p>The initial committers will focus on providing ease of use to those who work with more then a few models on their everyday work. Our agile development process will follow eclipse.org's standards for openness and transparency. Our goal is to provide the infrastructure and APIs and
	documentation needed to integrate downstream model developer's models with the building infrastructure and provide timely support on a dedicated eclipse newsgroup or within EMF newsgroup.
	</p><p>The initial committer is:
	<i>Hasan Ceylan</i> (batoo.org), has known to submit patches to a few eclipse projects, namely Platform, EMF DataBinding, Teneo, CDO, RAP, TMF/Xtend/Xpand, XWT, GEF, GMF, etc.
	</p><p><br>
	<b>Developer community</b>
	</p><p>As the context is limited we do not anticipate a significant interest in becoming contrubitor on the project.
	</p><p><br>
	<b>User community</b>
	</p><p>Project will try to collect ideas to improve and enhance the build process using EMF newgroup and eclipse.org provided bugzilla.
	</p><p><br>
	<b>Tentative Plan</b>

	</p><p><i>2010-02-08 v0.1.beta</i>
	milestone release with ECORE, XMI, GENMODEL validation and generation and limited dependency management. RELEASED
	</p><p><i>2010-03-06 v0.1.release</i>
	production release with full supportto ECORE, XMI, GENMODEL validation and generation and dependency management.
	</p><p><i>2010-03-19 v0.2.beta</i>
	milestone release with support for downstream model registration
	</p><p><i>2010-04-15 v0.2.beta</i>
	milestone release 1 with support for community requested enhancements
	</p><p><i>2010-05-07 v0.3.beta</i>
	milestone release 2 with support for community requested enhancements
	</p><p><i>2010-05-21 v1.0RC1</i>

	release candidate 1
	</p><p><i>2010-05-28 v1.0RC2</i>
	release candidate 2
	</p><p><i>2010-06-04 v1.0RC3</i>: release candidate 3
	</p><p><i>2010-06-11 v1.0RC3</i>: release candidate 4
	</p><p><i>2010-06-23 v1.0</i>: public release
	</p><p><i> +Helios Plan</i> is to migrate the project into EMF Core
	</p>
	<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>DD-Month-YYYY</td>
	<td>Document created</td>
	</tr>
	</table>
	</body>
	</html>