An issue I see with defining a builder is that it involves defining a
project nature which is something we've avoided in the core so far.
Automatically performing actions that can be fairly expensive, such as
validating all the Ecore models in the workspace, or generating all the
GenModels in the workspace, is also something I'd be reluctant about.
I suppose if it's done in the background, it's not such a concern. I
wonder how much of the benefit could achieved by enhancing the
GenerateHandler, e.g., to make it launch a job instead of blocking the IDE?

Hasan Ceylan wrote:
> The PDF has been attached...
>
>
>> Hello,
>>
>> Attached is the PDF version of the forementioned EMF Build Manager Project
>> Proposal.
>>
>> I kindly ask EMF community members and EMF (and subprojects) committers to
>> review the document and forward their thoughts.
>>
>> I am also looking for mentors for the proposal.
>>
>> Below is the extraction of "Background" of the project. Please remember to
>> review the attached PDF for full proposal draft.
>>
>> I apoligize for crossposting...
>>
>> ============================================================ =
>> BACKGROUND
>>
>> EMF has been around for a long time. But the fact is that it lacked the
>> necessary IDE Build Manager integration ever since.
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>> ============================================================ =
>>
>> Regards,
>>
>>
>
>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hasan,<br>
<br>
This posting only has your CV, but I found it in one of your other
cross posts.<br>
<br>
I think that the extremely well hidden generator wizard addresses many
of these concerns though there's certainly room for improvements:<br>
<blockquote><a
href=" http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-generate-my-28.html"> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-generate-my-28.html</a><br>
</blockquote>
An issue I see with defining a builder is that it involves defining a
project nature which is something we've avoided in the core so far.&nbsp;
Automatically performing actions that can be fairly expensive, such as
validating all the Ecore models in the workspace, or generating all the
GenModels in the workspace, is also something I'd be reluctant about.&nbsp;&nbsp;
I suppose if it's done in the background, it's not such a concern.&nbsp; I
wonder how much of the benefit could achieved by enhancing the
GenerateHandler, e.g., to make it launch a job instead of blocking the
IDE?<br>
<br>
<br>
Hasan Ceylan wrote:
<blockquote cite="mid:hk5qjg$41g$1@build.eclipse.org" type="cite">
<pre wrap="">The PDF has been attached...

</pre>
<blockquote type="cite">
<pre wrap="">Hello,

Attached is the PDF version of the forementioned EMF Build Manager Project
Proposal.

I kindly ask EMF community members and EMF (and subprojects) committers to
review the document and forward their thoughts.

I am also looking for mentors for the proposal.

Below is the extraction of "Background" of the project. Please remember to
review the attached PDF for full proposal draft.

EMF has been around for a long time. But the fact is that it lacked the
necessary IDE Build Manager integration ever since.
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.

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.

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.

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.

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