Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511333] Mon, 01 February 2010 05:07 Go to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070107050704000609090602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hasan,

This posting only has your CV, but I found it in one of your other cross
posts.

I think that the extremely well hidden generator wizard addresses many
of these concerns though there's certainly room for improvements:

http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-generate-my-28.html

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,
>>
>>
>
>

--------------070107050704000609090602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

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,

</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------070107050704000609090602--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511357 is a reply to message #511333] Mon, 01 February 2010 07:46 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad Varnica
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Post deleted......

[Updated on: Mon, 01 February 2010 08:14]

Report message to a moderator

Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511391 is a reply to message #511333] Mon, 01 February 2010 09:10 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Ed,

Thanks for sharing you comments. I will surely take a look at referenced
wizard / builder.

I think the project will handle situations like this well enough since:
1) It has built-in support for dependency chain, meaning only the affected
models in the change chain is marked for validation & generation
2) It is not a must, to have the nature to have an EMF project, since you
can add / remove the nature by project->right click
3) Builder triggers on save rather then "working-copy".
4) This can further be improved by adding a grace-period and / or max-depth
configuration. Meaning, consecutive changes to models within a time window
will gather changes and start the *real* build only after the grace period
expires. Reaching of *Max-depth* can place a mark on the status bar as well
as putting validation markers on the affected-but-yet-processed resources.
Clicking on the status bar notification or quick fix on the markers, can
trigger partition or deal with the rest of the process.
5) An unavoidable requirement of working with (even for XX number of
projects in a single workspace)is, whatever the chosen way of dealing with
EMF validation and build, eventually you have to generate. When this happens
EBM's promise is to relieve the workspace to the extent possible, with smart
dependency tracking and putting resource-locks on only the provisional
extension of the build process of the dirty models. This means, putting lock
only on the list of models in the dirty models and java package namespace of
the gemodels.
6) One of the nice features of the workspace resource locks is, say you are
working on a chanin of models. After some editing, you save your work, which
is where the builder kicks in. It certainly works in the background and as
long as you do not save an editor in the affected resources (chain of
dependency and genmodel java artifacts), further save blocks the UI if the
build is still going on. Here the user has option which includes
i) revertion the save request, which will go back to the editing domain
ii) Can halt the builder and postpone the build process altogether to a
futher time
7) Since the validation and generation do not modify the model resources
this has minimal impact on post-build dirt-editor merge.


One of the interesting outcome of my test with a sample workspace with 5
interdependent ecore + genmodel is while normally it takes about few
secconds to generate a genmodel, the whole process takes 2 times of that
time. I guess, this is due to, CPU caching and less processing and stack
operation due to less resortion to UI both in terms of painting and going
all the way down to OS UI bindings.

I am well aware of the cost of nature/builder integration for a relatively
large EMF workspace. But this is / can become a -no-longer-a-thread by
i) Smart handling of the models (Hey after all we arfe dealing with the
models right, which is exactly for this very reason)
2) Computers and processors evolved drastically since the introduction of
EMF. (that is about 8-10x) [1] [2]

Regards,
Hasan

[1] http://www.cpubenchmark.net/high_end_cpus.html
[2] http://www.cpubenchmark.net/low_end_cpus.html


Ed Merks wrote:

> Hasan,
>
> This posting only has your CV, but I found it in one of your other cross
> posts.
>
> I think that the extremely well hidden generator wizard addresses many
> of these concerns though there's certainly room for improvements:
>
> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
generate-my-28.html
>
> 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,
>>>
>>>
>>
>>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512211 is a reply to message #511391] Thu, 04 February 2010 07:20 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven

Hasan Ceylan schrieb:
> Hello Ed,
>
> Thanks for sharing you comments. I will surely take a look at referenced
> wizard / builder.
>
> I think the project will handle situations like this well enough since:
> 1) It has built-in support for dependency chain, meaning only the affected
> models in the change chain is marked for validation & generation
> 2) It is not a must, to have the nature to have an EMF project, since you
> can add / remove the nature by project->right click
> 3) Builder triggers on save rather then "working-copy".
> 4) This can further be improved by adding a grace-period and / or max-depth
> configuration. Meaning, consecutive changes to models within a time window
> will gather changes and start the *real* build only after the grace period
> expires. Reaching of *Max-depth* can place a mark on the status bar as well
> as putting validation markers on the affected-but-yet-processed resources.
> Clicking on the status bar notification or quick fix on the markers, can
> trigger partition or deal with the rest of the process.
> 5) An unavoidable requirement of working with (even for XX number of
> projects in a single workspace)is, whatever the chosen way of dealing with
> EMF validation and build, eventually you have to generate. When this happens
> EBM's promise is to relieve the workspace to the extent possible, with smart
> dependency tracking and putting resource-locks on only the provisional
> extension of the build process of the dirty models. This means, putting lock
> only on the list of models in the dirty models and java package namespace of
> the gemodels.
> 6) One of the nice features of the workspace resource locks is, say you are
> working on a chanin of models. After some editing, you save your work, which
> is where the builder kicks in. It certainly works in the background and as
> long as you do not save an editor in the affected resources (chain of
> dependency and genmodel java artifacts), further save blocks the UI if the
> build is still going on. Here the user has option which includes
> i) revertion the save request, which will go back to the editing domain
> ii) Can halt the builder and postpone the build process altogether to a
> futher time
> 7) Since the validation and generation do not modify the model resources
> this has minimal impact on post-build dirt-editor merge.
>
>
> One of the interesting outcome of my test with a sample workspace with 5
> interdependent ecore + genmodel is while normally it takes about few
> secconds to generate a genmodel, the whole process takes 2 times of that
> time. I guess, this is due to, CPU caching and less processing and stack
> operation due to less resortion to UI both in terms of painting and going
> all the way down to OS UI bindings.
>
> I am well aware of the cost of nature/builder integration for a relatively
> large EMF workspace. But this is / can become a -no-longer-a-thread by
> i) Smart handling of the models (Hey after all we arfe dealing with the
> models right, which is exactly for this very reason)
> 2) Computers and processors evolved drastically since the introduction of
> EMF. (that is about 8-10x) [1] [2]
>
> Regards,
> Hasan
>
> [1] http://www.cpubenchmark.net/high_end_cpus.html
> [2] http://www.cpubenchmark.net/low_end_cpus.html
>
>
> Ed Merks wrote:
>
>> Hasan,
>>
>> This posting only has your CV, but I found it in one of your other cross
>> posts.
>>
>> I think that the extremely well hidden generator wizard addresses many
>> of these concerns though there's certainly room for improvements:
>>
>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
> generate-my-28.html
>> 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,
>>>>
>>>>
>>>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512459 is a reply to message #512211] Fri, 05 February 2010 03:53 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Sven,

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a development bench?

Regards,
Hasan

Sven Efftinge wrote:

> Hi Hasan,
>
> how is this idea related to Xtext's builder infrastructure and EMF
> index? It seems to be a perfect match for what you want to achieve.
>
> Cheers,
> Sven
>
> Hasan Ceylan schrieb:
>> Hello Ed,
>>
>> Thanks for sharing you comments. I will surely take a look at referenced
>> wizard / builder.
>>
>> I think the project will handle situations like this well enough since:
>> 1) It has built-in support for dependency chain, meaning only the
>> affected models in the change chain is marked for validation & generation
>> 2) It is not a must, to have the nature to have an EMF project, since you
>> can add / remove the nature by project->right click
>> 3) Builder triggers on save rather then "working-copy".
>> 4) This can further be improved by adding a grace-period and / or
>> max-depth configuration. Meaning, consecutive changes to models within a
>> time window will gather changes and start the *real* build only after the
>> grace period expires. Reaching of *Max-depth* can place a mark on the
>> status bar as well as putting validation markers on the
>> affected-but-yet-processed resources. Clicking on the status bar
>> notification or quick fix on the markers, can trigger partition or deal
>> with the rest of the process. 5) An unavoidable requirement of working
>> with (even for XX number of projects in a single workspace)is, whatever
>> the chosen way of dealing with EMF validation and build, eventually you
>> have to generate. When this happens EBM's promise is to relieve the
>> workspace to the extent possible, with smart dependency tracking and
>> putting resource-locks on only the provisional extension of the build
>> process of the dirty models. This means, putting lock only on the list of
>> models in the dirty models and java package namespace of the gemodels.
>> 6) One of the nice features of the workspace resource locks is, say you
>> are working on a chanin of models. After some editing, you save your
>> work, which is where the builder kicks in. It certainly works in the
>> background and as long as you do not save an editor in the affected
>> resources (chain of dependency and genmodel java artifacts), further save
>> blocks the UI if the build is still going on. Here the user has option
>> which includes i) revertion the save request, which will go back to the
>> editing domain ii) Can halt the builder and postpone the build process
>> altogether to a futher time
>> 7) Since the validation and generation do not modify the model resources
>> this has minimal impact on post-build dirt-editor merge.
>>
>>
>> One of the interesting outcome of my test with a sample workspace with 5
>> interdependent ecore + genmodel is while normally it takes about few
>> secconds to generate a genmodel, the whole process takes 2 times of that
>> time. I guess, this is due to, CPU caching and less processing and stack
>> operation due to less resortion to UI both in terms of painting and going
>> all the way down to OS UI bindings.
>>
>> I am well aware of the cost of nature/builder integration for a
>> relatively large EMF workspace. But this is / can become a
>> -no-longer-a-thread by i) Smart handling of the models (Hey after all we
>> arfe dealing with the models right, which is exactly for this very
>> reason) 2) Computers and processors evolved drastically since the
>> introduction of EMF. (that is about 8-10x) [1] [2]
>>
>> Regards,
>> Hasan
>>
>> [1] http://www.cpubenchmark.net/high_end_cpus.html
>> [2] http://www.cpubenchmark.net/low_end_cpus.html
>>
>>
>> Ed Merks wrote:
>>
>>> Hasan,
>>>
>>> This posting only has your CV, but I found it in one of your other cross
>>> posts.
>>>
>>> I think that the extremely well hidden generator wizard addresses many
>>> of these concerns though there's certainly room for improvements:
>>>
>>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
>> generate-my-28.html
>>> 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,
>>>>>
>>>>>
>>>>
>>
>
>

--

Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647


From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."

--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512479 is a reply to message #512459] Fri, 05 February 2010 04:20 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore and
genmodel. This makes sure that ecore and genmodel are indexed. It also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&n document
see M5/ProjectBuilder
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)

Sven

Hasan Ceylan schrieb:
> Hello Sven,
>
> Would love to test with Xtext + EMF Index bench.
>
> Would you be so kind to give me directions to set up a development bench?
>
> Regards,
> Hasan
>
> Sven Efftinge wrote:
>
>> Hi Hasan,
>>
>> how is this idea related to Xtext's builder infrastructure and EMF
>> index? It seems to be a perfect match for what you want to achieve.
>>
>> Cheers,
>> Sven
>>
>> Hasan Ceylan schrieb:
>>> Hello Ed,
>>>
>>> Thanks for sharing you comments. I will surely take a look at referenced
>>> wizard / builder.
>>>
>>> I think the project will handle situations like this well enough since:
>>> 1) It has built-in support for dependency chain, meaning only the
>>> affected models in the change chain is marked for validation & generation
>>> 2) It is not a must, to have the nature to have an EMF project, since you
>>> can add / remove the nature by project->right click
>>> 3) Builder triggers on save rather then "working-copy".
>>> 4) This can further be improved by adding a grace-period and / or
>>> max-depth configuration. Meaning, consecutive changes to models within a
>>> time window will gather changes and start the *real* build only after the
>>> grace period expires. Reaching of *Max-depth* can place a mark on the
>>> status bar as well as putting validation markers on the
>>> affected-but-yet-processed resources. Clicking on the status bar
>>> notification or quick fix on the markers, can trigger partition or deal
>>> with the rest of the process. 5) An unavoidable requirement of working
>>> with (even for XX number of projects in a single workspace)is, whatever
>>> the chosen way of dealing with EMF validation and build, eventually you
>>> have to generate. When this happens EBM's promise is to relieve the
>>> workspace to the extent possible, with smart dependency tracking and
>>> putting resource-locks on only the provisional extension of the build
>>> process of the dirty models. This means, putting lock only on the list of
>>> models in the dirty models and java package namespace of the gemodels.
>>> 6) One of the nice features of the workspace resource locks is, say you
>>> are working on a chanin of models. After some editing, you save your
>>> work, which is where the builder kicks in. It certainly works in the
>>> background and as long as you do not save an editor in the affected
>>> resources (chain of dependency and genmodel java artifacts), further save
>>> blocks the UI if the build is still going on. Here the user has option
>>> which includes i) revertion the save request, which will go back to the
>>> editing domain ii) Can halt the builder and postpone the build process
>>> altogether to a futher time
>>> 7) Since the validation and generation do not modify the model resources
>>> this has minimal impact on post-build dirt-editor merge.
>>>
>>>
>>> One of the interesting outcome of my test with a sample workspace with 5
>>> interdependent ecore + genmodel is while normally it takes about few
>>> secconds to generate a genmodel, the whole process takes 2 times of that
>>> time. I guess, this is due to, CPU caching and less processing and stack
>>> operation due to less resortion to UI both in terms of painting and going
>>> all the way down to OS UI bindings.
>>>
>>> I am well aware of the cost of nature/builder integration for a
>>> relatively large EMF workspace. But this is / can become a
>>> -no-longer-a-thread by i) Smart handling of the models (Hey after all we
>>> arfe dealing with the models right, which is exactly for this very
>>> reason) 2) Computers and processors evolved drastically since the
>>> introduction of EMF. (that is about 8-10x) [1] [2]
>>>
>>> Regards,
>>> Hasan
>>>
>>> [1] http://www.cpubenchmark.net/high_end_cpus.html
>>> [2] http://www.cpubenchmark.net/low_end_cpus.html
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Hasan,
>>>>
>>>> This posting only has your CV, but I found it in one of your other cross
>>>> posts.
>>>>
>>>> I think that the extremely well hidden generator wizard addresses many
>>>> of these concerns though there's certainly room for improvements:
>>>>
>>>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
>>> generate-my-28.html
>>>> 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,
>>>>>>
>>>>>>
>>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512491 is a reply to message #512479] Fri, 05 February 2010 00:02 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Sven,

I'm a bit confused.

The aim of EMF Builder is to validate and generate java artifacts on ecore,
xmi and genmodel based on changes on the resources. Basically automates what
you would do when you have an ecore and a genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and generates the
dependent models)

XText does this automatically with the mwe runner. Are you suggesting
integrating the xtext mwe into EMFBuilder so that the generation is
automated? I just couldn't get it, sorry

Hasan

Sven Efftinge wrote:

>
> With Xtext M5 it is basically a matter of
> a) implementing and registering IResourceServiceProvider for ecore and
> genmodel. This makes sure that ecore and genmodel are indexed. It also
> provides the needed hook to compute the transitive hull of changes.
>
> b) implementing and registering IBuildParticipant.
> This one get's a call after each build passed in the
> IResourceDescription.Deltas. Based on that you'll be able to trigger
> code generation.
>
> There's a short video demonstrating the second hook in our n&n document
> see M5/ProjectBuilder
> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>
> Sven
>
> Hasan Ceylan schrieb:
>> Hello Sven,
>>
>> Would love to test with Xtext + EMF Index bench.
>>
>> Would you be so kind to give me directions to set up a development bench?
>>
>> Regards,
>> Hasan
>>
>> Sven Efftinge wrote:
>>
>>> Hi Hasan,
>>>
>>> how is this idea related to Xtext's builder infrastructure and EMF
>>> index? It seems to be a perfect match for what you want to achieve.
>>>
>>> Cheers,
>>> Sven
>>>
<SNIP>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512498 is a reply to message #512491] Fri, 05 February 2010 00:14 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Hasan Ceylan schrieb:
> The aim of EMF Builder is to validate and generate java artifacts on ecore,
> xmi and genmodel based on changes on the resources. Basically automates what
> you would do when you have an ecore and a genodel:
> 1) Change the ecore
> 2) open genmodel
> 3) Issue generate all
>
> and does this with the dependencies considered (validates and generates the
> dependent models)
>
> XText does this automatically with the mwe runner. Are you suggesting
> integrating the xtext mwe into EMFBuilder so that the generation is
> automated? I just couldn't get it, sorry

No, I didn't meant anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it provides
two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based on
the outcome of a build. (E.g. to start the generation of any affected
genmodels and epackages).

I have blogged about the builder infrastructure in general:
http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html

The participant hook had been introduced with M5 and is demoed on the
new & noteworthy page.

Cheers,
Sven


>
> Hasan
>
> Sven Efftinge wrote:
>
>> With Xtext M5 it is basically a matter of
>> a) implementing and registering IResourceServiceProvider for ecore and
>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>> provides the needed hook to compute the transitive hull of changes.
>>
>> b) implementing and registering IBuildParticipant.
>> This one get's a call after each build passed in the
>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>> code generation.
>>
>> There's a short video demonstrating the second hook in our n&n document
>> see M5/ProjectBuilder
>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>
>> Sven
>>
>> Hasan Ceylan schrieb:
>>> Hello Sven,
>>>
>>> Would love to test with Xtext + EMF Index bench.
>>>
>>> Would you be so kind to give me directions to set up a development bench?
>>>
>>> Regards,
>>> Hasan
>>>
>>> Sven Efftinge wrote:
>>>
>>>> Hi Hasan,
>>>>
>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
> <SNIP>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512523 is a reply to message #512498] Fri, 05 February 2010 01:24 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Sven,

This sounds cool too, and definitely related. I wonder if something of
general utility like this makes sense to separate out from Xtext itself?

Sven Efftinge wrote:
> Hasan Ceylan schrieb:
>> The aim of EMF Builder is to validate and generate java artifacts on
>> ecore, xmi and genmodel based on changes on the resources. Basically
>> automates what you would do when you have an ecore and a genodel:
>> 1) Change the ecore
>> 2) open genmodel
>> 3) Issue generate all
>>
>> and does this with the dependencies considered (validates and
>> generates the dependent models)
>>
>> XText does this automatically with the mwe runner. Are you suggesting
>> integrating the xtext mwe into EMFBuilder so that the generation is
>> automated? I just couldn't get it, sorry
>
> No, I didn't meant anything MWE related. I was talking of the new
> builder infraststructure in Xtext.
> It is just exactly what you have in mind. It listenes on resource
> changes (is triggered on save), it computes the transtive hull of
> affected resources, it validates the affected resources and it
> provides two extension points:
> 1) one to register EMF-based languages (they don't have to be Xtext
> languages) (e.g. *.ecore, *.genmodel)
> 2) one to register participants, which can do arbitrary work based on
> the outcome of a build. (E.g. to start the generation of any affected
> genmodels and epackages).
>
> I have blogged about the builder infrastructure in general:
> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>
> The participant hook had been introduced with M5 and is demoed on the
> new & noteworthy page.
>
> Cheers,
> Sven
>
>
>>
>> Hasan
>>
>> Sven Efftinge wrote:
>>
>>> With Xtext M5 it is basically a matter of
>>> a) implementing and registering IResourceServiceProvider for ecore and
>>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>>> provides the needed hook to compute the transitive hull of changes.
>>>
>>> b) implementing and registering IBuildParticipant.
>>> This one get's a call after each build passed in the
>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>> code generation.
>>>
>>> There's a short video demonstrating the second hook in our n&n document
>>> see M5/ProjectBuilder
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>> Sven
>>>
>>> Hasan Ceylan schrieb:
>>>> Hello Sven,
>>>>
>>>> Would love to test with Xtext + EMF Index bench.
>>>>
>>>> Would you be so kind to give me directions to set up a development
>>>> bench?
>>>>
>>>> Regards,
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hi Hasan,
>>>>>
>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>> <SNIP>
>>
>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512597 is a reply to message #512523] Fri, 05 February 2010 10:01 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:
> Sven,
>
> This sounds cool too, and definitely related. I wonder if something of
> general utility like this makes sense to separate out from Xtext itself?
>
> Sven Efftinge wrote:
>> Hasan Ceylan schrieb:
>>> The aim of EMF Builder is to validate and generate java artifacts on
>>> ecore, xmi and genmodel based on changes on the resources. Basically
>>> automates what you would do when you have an ecore and a genodel:
>>> 1) Change the ecore
>>> 2) open genmodel
>>> 3) Issue generate all
>>>
>>> and does this with the dependencies considered (validates and
>>> generates the dependent models)
>>>
>>> XText does this automatically with the mwe runner. Are you suggesting
>>> integrating the xtext mwe into EMFBuilder so that the generation is
>>> automated? I just couldn't get it, sorry
>>
>> No, I didn't meant anything MWE related. I was talking of the new
>> builder infraststructure in Xtext.
>> It is just exactly what you have in mind. It listenes on resource
>> changes (is triggered on save), it computes the transtive hull of
>> affected resources, it validates the affected resources and it
>> provides two extension points:
>> 1) one to register EMF-based languages (they don't have to be Xtext
>> languages) (e.g. *.ecore, *.genmodel)
>> 2) one to register participants, which can do arbitrary work based on
>> the outcome of a build. (E.g. to start the generation of any affected
>> genmodels and epackages).
>>
>> I have blogged about the builder infrastructure in general:
>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>
>> The participant hook had been introduced with M5 and is demoed on the
>> new & noteworthy page.
>>
>> Cheers,
>> Sven
>>
>>
>>>
>>> Hasan
>>>
>>> Sven Efftinge wrote:
>>>
>>>> With Xtext M5 it is basically a matter of
>>>> a) implementing and registering IResourceServiceProvider for ecore and
>>>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>>>> provides the needed hook to compute the transitive hull of changes.
>>>>
>>>> b) implementing and registering IBuildParticipant.
>>>> This one get's a call after each build passed in the
>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>> code generation.
>>>>
>>>> There's a short video demonstrating the second hook in our n&n document
>>>> see M5/ProjectBuilder
>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>
>>>>
>>>> Sven
>>>>
>>>> Hasan Ceylan schrieb:
>>>>> Hello Sven,
>>>>>
>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>
>>>>> Would you be so kind to give me directions to set up a development
>>>>> bench?
>>>>>
>>>>> Regards,
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hi Hasan,
>>>>>>
>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>> <SNIP>
>>>
>>
>>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512710 is a reply to message #512597] Sat, 06 February 2010 12:33 Go to previous messageGo to next message
Sven Krause is currently offline Sven Krause
Messages: 64
Registered: July 2009
Member
Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:
> Yes, I think it definitely makes sense at some point.
> Maybe we should work on extracting that functionality during the next
> release train?
>
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> This sounds cool too, and definitely related. I wonder if something
>> of general utility like this makes sense to separate out from Xtext
>> itself?
>>
>> Sven Efftinge wrote:
>>> Hasan Ceylan schrieb:
>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>> Basically automates what you would do when you have an ecore and a
>>>> genodel:
>>>> 1) Change the ecore
>>>> 2) open genmodel
>>>> 3) Issue generate all
>>>>
>>>> and does this with the dependencies considered (validates and
>>>> generates the dependent models)
>>>>
>>>> XText does this automatically with the mwe runner. Are you
>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>> generation is automated? I just couldn't get it, sorry
>>>
>>> No, I didn't meant anything MWE related. I was talking of the new
>>> builder infraststructure in Xtext.
>>> It is just exactly what you have in mind. It listenes on resource
>>> changes (is triggered on save), it computes the transtive hull of
>>> affected resources, it validates the affected resources and it
>>> provides two extension points:
>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>> languages) (e.g. *.ecore, *.genmodel)
>>> 2) one to register participants, which can do arbitrary work based
>>> on the outcome of a build. (E.g. to start the generation of any
>>> affected genmodels and epackages).
>>>
>>> I have blogged about the builder infrastructure in general:
>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>
>>> The participant hook had been introduced with M5 and is demoed on
>>> the new & noteworthy page.
>>>
>>> Cheers,
>>> Sven
>>>
>>>
>>>>
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> With Xtext M5 it is basically a matter of
>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>> and
>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>> also
>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>
>>>>> b) implementing and registering IBuildParticipant.
>>>>> This one get's a call after each build passed in the
>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>> code generation.
>>>>>
>>>>> There's a short video demonstrating the second hook in our n&n
>>>>> document
>>>>> see M5/ProjectBuilder
>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>
>>>>>
>>>>> Sven
>>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>> Hello Sven,
>>>>>>
>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>
>>>>>> Would you be so kind to give me directions to set up a
>>>>>> development bench?
>>>>>>
>>>>>> Regards,
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hi Hasan,
>>>>>>>
>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>> <SNIP>
>>>>
>>>
>>>
>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512721 is a reply to message #512710] Sat, 06 February 2010 12:56 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080709090205030609010102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sven,

What the other Sven described sounded quite general along the lines of
what you're suggesting. It would certainly be good in such a framework
to make a validation cycle trivial to enable, i.e., just an extension
with a generic reusable validator trigger.


Sven Krause wrote:
> Hi Hasan, Sven, Ed,
>
> wouldn't it make sense to have such an background build/gen job not only
> limited to ecore/gen/xtext? The most emf based models are registered
> with its package factory and the potential file extension. So it should
> be easily possible to identify each kind of model of model files within
> the marked projects and launch the generic validate/build build hook for
> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
> a special case. PS:the change of a base model might/should trigger the
> dependent model build cycle too.
>
> Sven
>
> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>
>> Yes, I think it definitely makes sense at some point.
>> Maybe we should work on extracting that functionality during the next
>> release train?
>>
>> Sven
>>
>> Ed Merks schrieb:
>>
>>> Sven,
>>>
>>> This sounds cool too, and definitely related. I wonder if something
>>> of general utility like this makes sense to separate out from Xtext
>>> itself?
>>>
>>> Sven Efftinge wrote:
>>>
>>>> Hasan Ceylan schrieb:
>>>>
>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>> Basically automates what you would do when you have an ecore and a
>>>>> genodel:
>>>>> 1) Change the ecore
>>>>> 2) open genmodel
>>>>> 3) Issue generate all
>>>>>
>>>>> and does this with the dependencies considered (validates and
>>>>> generates the dependent models)
>>>>>
>>>>> XText does this automatically with the mwe runner. Are you
>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>> generation is automated? I just couldn't get it, sorry
>>>>>
>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>> builder infraststructure in Xtext.
>>>> It is just exactly what you have in mind. It listenes on resource
>>>> changes (is triggered on save), it computes the transtive hull of
>>>> affected resources, it validates the affected resources and it
>>>> provides two extension points:
>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>> languages) (e.g. *.ecore, *.genmodel)
>>>> 2) one to register participants, which can do arbitrary work based
>>>> on the outcome of a build. (E.g. to start the generation of any
>>>> affected genmodels and epackages).
>>>>
>>>> I have blogged about the builder infrastructure in general:
>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>
>>>> The participant hook had been introduced with M5 and is demoed on
>>>> the new & noteworthy page.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
>>>>
>>>>
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>
>>>>>> With Xtext M5 it is basically a matter of
>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>> and
>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>> also
>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>
>>>>>> b) implementing and registering IBuildParticipant.
>>>>>> This one get's a call after each build passed in the
>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>> code generation.
>>>>>>
>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>> document
>>>>>> see M5/ProjectBuilder
>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>
>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>> development bench?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Hasan,
>>>>>>>>
>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sven
>>>>>>>>
>>>>>>>>
>>>>> <SNIP>
>>>>>
>>>>>
>>>>
>>
>
>

--------------080709090205030609010102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sven,<br>
<br>
What the other Sven described sounded quite general along the lines of
what you're suggesting.&nbsp; It would certainly be good in such a framework
to make a validation cycle trivial to enable, i.e., just an extension
with a generic reusable validator trigger.<br>
<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:hkk94l$h59$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Sven,

This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?

Sven Efftinge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hasan Ceylan schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">The aim of EMF Builder is to validate and generate java artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and
generates the dependent models)

XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
</pre>
</blockquote>
<pre wrap="">No, I didn't meant anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).

I have blogged about the builder infrastructure in general:
<a class="moz-txt-link-freetext" href=" http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html"> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html</a>

The participant hook had been introduced with M5 and is demoed on
the new &amp; noteworthy page.

Cheers,
Sven


</pre>
<blockquote type="cite">
<pre wrap="">Hasan

Sven Efftinge wrote:

</pre>
<blockquote type="cite">
<pre wrap="">With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&amp;n
document
see M5/ProjectBuilder
(<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php"> http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php</a>)


Sven

Hasan Ceylan schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Sven,

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a
development bench?

Regards,
Hasan

Sven Efftinge wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven

</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">&lt;SNIP&gt;

</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------080709090205030609010102--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512722 is a reply to message #512721] Sat, 06 February 2010 13:17 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Yes, Xtext's builder infrastructure is not specific to Xtext or ecore,
but allows to "build" any kind of EMF resource in the workspace.
However, we do not reuse the ResourceFactory.Registry.INSTANCE but have
a Registry for so called IResourceServiceProviders.
So if you want to have your EMF models built, just implement and
register one.

Cheers,
Sven

Ed Merks schrieb:
> Sven,
>
> What the other Sven described sounded quite general along the lines of
> what you're suggesting. It would certainly be good in such a framework
> to make a validation cycle trivial to enable, i.e., just an extension
> with a generic reusable validator trigger.
>
>
> Sven Krause wrote:
>> Hi Hasan, Sven, Ed,
>>
>> wouldn't it make sense to have such an background build/gen job not only
>> limited to ecore/gen/xtext? The most emf based models are registered
>> with its package factory and the potential file extension. So it should
>> be easily possible to identify each kind of model of model files within
>> the marked projects and launch the generic validate/build build hook for
>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>> a special case. PS:the change of a base model might/should trigger the
>> dependent model build cycle too.
>>
>> Sven
>>
>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>
>>> Yes, I think it definitely makes sense at some point.
>>> Maybe we should work on extracting that functionality during the next
>>> release train?
>>>
>>> Sven
>>>
>>> Ed Merks schrieb:
>>>
>>>> Sven,
>>>>
>>>> This sounds cool too, and definitely related. I wonder if something
>>>> of general utility like this makes sense to separate out from Xtext
>>>> itself?
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>
>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>> genodel:
>>>>>> 1) Change the ecore
>>>>>> 2) open genmodel
>>>>>> 3) Issue generate all
>>>>>>
>>>>>> and does this with the dependencies considered (validates and
>>>>>> generates the dependent models)
>>>>>>
>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>
>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>> builder infraststructure in Xtext.
>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>> affected resources, it validates the affected resources and it
>>>>> provides two extension points:
>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>> 2) one to register participants, which can do arbitrary work based
>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>> affected genmodels and epackages).
>>>>>
>>>>> I have blogged about the builder infrastructure in general:
>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>
>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>> the new & noteworthy page.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>> and
>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>> also
>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>
>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>> This one get's a call after each build passed in the
>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>> code generation.
>>>>>>>
>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>> document
>>>>>>> see M5/ProjectBuilder
>>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>>
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> Hello Sven,
>>>>>>>>
>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>
>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>> development bench?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Hasan,
>>>>>>>>>
>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>> <SNIP>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512729 is a reply to message #512710] Sat, 06 February 2010 08:44 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Sven,

First you may find the proposal draft here:
http://ebm.batoo.org/index.php/Main_Page

and, yes I definitely target a cycle with the dependencies resolved both in
the workspace and emf registry, and any change / error flag transitively
will affect the downstream models.

Frankly I hadn't though about caching all the extension from the registry. I
should add that as an enhancement request.

Hasan

Sven Krause wrote:

> Hi Hasan, Sven, Ed,
>
> wouldn't it make sense to have such an background build/gen job not only
> limited to ecore/gen/xtext? The most emf based models are registered
> with its package factory and the potential file extension. So it should
> be easily possible to identify each kind of model of model files within
> the marked projects and launch the generic validate/build build hook for
> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
> a special case. PS:the change of a base model might/should trigger the
> dependent model build cycle too.
>
> Sven
>
> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>> Yes, I think it definitely makes sense at some point.
>> Maybe we should work on extracting that functionality during the next
>> release train?
>>
>> Sven
>>
>> Ed Merks schrieb:
>>> Sven,
>>>
>>> This sounds cool too, and definitely related. I wonder if something
>>> of general utility like this makes sense to separate out from Xtext
>>> itself?
>>>
>>> Sven Efftinge wrote:
>>>> Hasan Ceylan schrieb:
>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>> Basically automates what you would do when you have an ecore and a
>>>>> genodel:
>>>>> 1) Change the ecore
>>>>> 2) open genmodel
>>>>> 3) Issue generate all
>>>>>
>>>>> and does this with the dependencies considered (validates and
>>>>> generates the dependent models)
>>>>>
>>>>> XText does this automatically with the mwe runner. Are you
>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>> generation is automated? I just couldn't get it, sorry
>>>>
>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>> builder infraststructure in Xtext.
>>>> It is just exactly what you have in mind. It listenes on resource
>>>> changes (is triggered on save), it computes the transtive hull of
>>>> affected resources, it validates the affected resources and it
>>>> provides two extension points:
>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>> languages) (e.g. *.ecore, *.genmodel)
>>>> 2) one to register participants, which can do arbitrary work based
>>>> on the outcome of a build. (E.g. to start the generation of any
>>>> affected genmodels and epackages).
>>>>
>>>> I have blogged about the builder infrastructure in general:
>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>
>>>> The participant hook had been introduced with M5 and is demoed on
>>>> the new & noteworthy page.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
>>>>
>>>>>
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> With Xtext M5 it is basically a matter of
>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>> and
>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>> also
>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>
>>>>>> b) implementing and registering IBuildParticipant.
>>>>>> This one get's a call after each build passed in the
>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>> code generation.
>>>>>>
>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>> document
>>>>>> see M5/ProjectBuilder
>>>>>>
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>
>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>> development bench?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>> Hi Hasan,
>>>>>>>>
>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sven
>>>>>>>>
>>>>> <SNIP>
>>>>>
>>>>
>>>>
>>
>>

--

Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647


From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."

--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512756 is a reply to message #512729] Sat, 06 February 2010 23:44 Go to previous messageGo to next message
Sven Krause is currently offline Sven Krause
Messages: 64
Registered: July 2009
Member
Hi Hasan, Sven

we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?

Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
> Hello Sven,
>
> First you may find the proposal draft here:
> http://ebm.batoo.org/index.php/Main_Page
>
> and, yes I definitely target a cycle with the dependencies resolved both in
> the workspace and emf registry, and any change / error flag transitively
> will affect the downstream models.
>
> Frankly I hadn't though about caching all the extension from the registry. I
> should add that as an enhancement request.
>
> Hasan
>
> Sven Krause wrote:
>
>
>> Hi Hasan, Sven, Ed,
>>
>> wouldn't it make sense to have such an background build/gen job not only
>> limited to ecore/gen/xtext? The most emf based models are registered
>> with its package factory and the potential file extension. So it should
>> be easily possible to identify each kind of model of model files within
>> the marked projects and launch the generic validate/build build hook for
>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>> a special case. PS:the change of a base model might/should trigger the
>> dependent model build cycle too.
>>
>> Sven
>>
>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>
>>> Yes, I think it definitely makes sense at some point.
>>> Maybe we should work on extracting that functionality during the next
>>> release train?
>>>
>>> Sven
>>>
>>> Ed Merks schrieb:
>>>
>>>> Sven,
>>>>
>>>> This sounds cool too, and definitely related. I wonder if something
>>>> of general utility like this makes sense to separate out from Xtext
>>>> itself?
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>
>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>> genodel:
>>>>>> 1) Change the ecore
>>>>>> 2) open genmodel
>>>>>> 3) Issue generate all
>>>>>>
>>>>>> and does this with the dependencies considered (validates and
>>>>>> generates the dependent models)
>>>>>>
>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>
>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>> builder infraststructure in Xtext.
>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>> affected resources, it validates the affected resources and it
>>>>> provides two extension points:
>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>> 2) one to register participants, which can do arbitrary work based
>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>> affected genmodels and epackages).
>>>>>
>>>>> I have blogged about the builder infrastructure in general:
>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>
>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>> the new & noteworthy page.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>> and
>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>> also
>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>
>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>> This one get's a call after each build passed in the
>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>> code generation.
>>>>>>>
>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>> document
>>>>>>> see M5/ProjectBuilder
>>>>>>>
>>>>>>>
> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> Hello Sven,
>>>>>>>>
>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>
>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>> development bench?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Hasan,
>>>>>>>>>
>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>> <SNIP>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512757 is a reply to message #512722] Sat, 06 February 2010 23:44 Go to previous messageGo to next message
Sven Krause is currently offline Sven Krause
Messages: 64
Registered: July 2009
Member
Hi Sven,

doesn't put this construct extra effort in allowing trigger builds on
any model or did use this explicit as filter?

Sven
Am 06.02.2010 19:17, schrieb Sven Efftinge:
> Yes, Xtext's builder infrastructure is not specific to Xtext or ecore,
> but allows to "build" any kind of EMF resource in the workspace.
> However, we do not reuse the ResourceFactory.Registry.INSTANCE but
> have a Registry for so called IResourceServiceProviders.
> So if you want to have your EMF models built, just implement and
> register one.
>
> Cheers,
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> What the other Sven described sounded quite general along the lines
>> of what you're suggesting. It would certainly be good in such a
>> framework to make a validation cycle trivial to enable, i.e., just an
>> extension with a generic reusable validator trigger.
>>
>>
>> Sven Krause wrote:
>>> Hi Hasan, Sven, Ed,
>>>
>>> wouldn't it make sense to have such an background build/gen job not
>>> only
>>> limited to ecore/gen/xtext? The most emf based models are registered
>>> with its package factory and the potential file extension. So it should
>>> be easily possible to identify each kind of model of model files within
>>> the marked projects and launch the generic validate/build build hook
>>> for
>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>> a special case. PS:the change of a base model might/should trigger the
>>> dependent model build cycle too.
>>>
>>> Sven
>>>
>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>
>>>> Yes, I think it definitely makes sense at some point.
>>>> Maybe we should work on extracting that functionality during the next
>>>> release train?
>>>>
>>>> Sven
>>>>
>>>> Ed Merks schrieb:
>>>>
>>>>> Sven,
>>>>>
>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>> of general utility like this makes sense to separate out from Xtext
>>>>> itself?
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>> genodel:
>>>>>>> 1) Change the ecore
>>>>>>> 2) open genmodel
>>>>>>> 3) Issue generate all
>>>>>>>
>>>>>>> and does this with the dependencies considered (validates and
>>>>>>> generates the dependent models)
>>>>>>>
>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>
>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>> builder infraststructure in Xtext.
>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>> affected resources, it validates the affected resources and it
>>>>>> provides two extension points:
>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>> affected genmodels and epackages).
>>>>>>
>>>>>> I have blogged about the builder infrastructure in general:
>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>
>>>>>>
>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>> the new & noteworthy page.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>> and
>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>> also
>>>>>>>> provides the needed hook to compute the transitive hull of
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>> This one get's a call after each build passed in the
>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to
>>>>>>>> trigger
>>>>>>>> code generation.
>>>>>>>>
>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>> document
>>>>>>>> see M5/ProjectBuilder
>>>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>
>>>>>>>>> Hello Sven,
>>>>>>>>>
>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>
>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>> development bench?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hasan
>>>>>>>>>
>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Hasan,
>>>>>>>>>>
>>>>>>>>>> how is this idea related to Xtext's builder infrastructure
>>>>>>>>>> and EMF
>>>>>>>>>> index? It seems to be a perfect match for what you want to
>>>>>>>>>> achieve.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512774 is a reply to message #512756] Sun, 07 February 2010 04:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050704030205090700090909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

A separate builder project seems like a good thing. It seems closely
related to the Sphinx proposal as well, so it might make sense for it to
be part of that too...

Sven Krause wrote:
> Hi Hasan, Sven
>
> we have similar capabilities in the flowr project that became base of
> the new mtf eclipse project. Are you interested to join the project and
> bring your features into mtf? Or do you prefer to keep it standalone
> (@Ed, Sven)?
>
> Sven
> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>
>> Hello Sven,
>>
>> First you may find the proposal draft here:
>> http://ebm.batoo.org/index.php/Main_Page
>>
>> and, yes I definitely target a cycle with the dependencies resolved both in
>> the workspace and emf registry, and any change / error flag transitively
>> will affect the downstream models.
>>
>> Frankly I hadn't though about caching all the extension from the registry. I
>> should add that as an enhancement request.
>>
>> Hasan
>>
>> Sven Krause wrote:
>>
>>
>>
>>> Hi Hasan, Sven, Ed,
>>>
>>> wouldn't it make sense to have such an background build/gen job not only
>>> limited to ecore/gen/xtext? The most emf based models are registered
>>> with its package factory and the potential file extension. So it should
>>> be easily possible to identify each kind of model of model files within
>>> the marked projects and launch the generic validate/build build hook for
>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>> a special case. PS:the change of a base model might/should trigger the
>>> dependent model build cycle too.
>>>
>>> Sven
>>>
>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>
>>>
>>>> Yes, I think it definitely makes sense at some point.
>>>> Maybe we should work on extracting that functionality during the next
>>>> release train?
>>>>
>>>> Sven
>>>>
>>>> Ed Merks schrieb:
>>>>
>>>>
>>>>> Sven,
>>>>>
>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>> of general utility like this makes sense to separate out from Xtext
>>>>> itself?
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>
>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>> genodel:
>>>>>>> 1) Change the ecore
>>>>>>> 2) open genmodel
>>>>>>> 3) Issue generate all
>>>>>>>
>>>>>>> and does this with the dependencies considered (validates and
>>>>>>> generates the dependent models)
>>>>>>>
>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>
>>>>>>>
>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>> builder infraststructure in Xtext.
>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>> affected resources, it validates the affected resources and it
>>>>>> provides two extension points:
>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>> affected genmodels and epackages).
>>>>>>
>>>>>> I have blogged about the builder infrastructure in general:
>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>
>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>> the new & noteworthy page.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>> and
>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>> also
>>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>>
>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>> This one get's a call after each build passed in the
>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>>> code generation.
>>>>>>>>
>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>> document
>>>>>>>> see M5/ProjectBuilder
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>
>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hello Sven,
>>>>>>>>>
>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>
>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>> development bench?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hasan
>>>>>>>>>
>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Hasan,
>>>>>>>>>>
>>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>

--------------050704030205090700090909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!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">
A separate builder project seems like a good thing.&nbsp; It seems closely
related to the Sphinx proposal as well, so it might make sense for it
to be part of that too...<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:hkm1dc$1js$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Hasan, Sven

we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?

Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Sven,

First you may find the proposal draft here:
<a class="moz-txt-link-freetext" href="http://ebm.batoo.org/index.php/Main_Page">http://ebm.batoo.org/index.php/Main_Page</a>

and, yes I definitely target a cycle with the dependencies resolved both in
the workspace and emf registry, and any change / error flag transitively
will affect the downstream models.

Frankly I hadn't though about caching all the extension from the registry. I
should add that as an enhancement request.

Hasan

Sven Krause wrote:


</pre>
<blockquote type="cite">
<pre wrap="">Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:

</pre>
<blockquote type="cite">
<pre wrap="">Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:

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

This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?

Sven Efftinge wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hasan Ceylan schrieb:

</pre>
<blockquote type="cite">
<pre wrap="">The aim of EMF Builder is to validate and generate java artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and
generates the dependent models)

XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry

</pre>
</blockquote>
<pre wrap="">No, I didn't meant anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).

I have blogged about the builder infrastructure in general:
<a class="moz-txt-link-freetext" href=" http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html"> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html</a>

The participant hook had been introduced with M5 and is demoed on
the new &amp; noteworthy page.

Cheers,
Sven



</pre>
<blockquote type="cite">
<pre wrap="">Hasan

Sven Efftinge wrote:


</pre>
<blockquote type="cite">
<pre wrap="">With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&amp;n
document
see M5/ProjectBuilder


</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">(<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php"> http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php</a>)

</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Sven

Hasan Ceylan schrieb:

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

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a
development bench?

Regards,
Hasan

Sven Efftinge wrote:


</pre>
<blockquote type="cite">
<pre wrap="">Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven


</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">&lt;SNIP&gt;


</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------050704030205090700090909--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512844 is a reply to message #512774] Sun, 07 February 2010 21:46 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
I think it's clearly in the scope of the EMF Index project.
See http://www.eclipse.org/proposals/emf-index/

"""
Define APIs and implement components for specifying search scopes,
collecting and persisting index data, synchronization of index data with
model changes, and querying of model elements.
"""

The Sphinx project seems to have a rather wide scope. I think we should
tune its scope a bit, but that belongs to a different thread (and
newsgroup).

Cheers,
Sven

Ed Merks schrieb:
> A separate builder project seems like a good thing. It seems closely
> related to the Sphinx proposal as well, so it might make sense for it to
> be part of that too...
>
> Sven Krause wrote:
>> Hi Hasan, Sven
>>
>> we have similar capabilities in the flowr project that became base of
>> the new mtf eclipse project. Are you interested to join the project and
>> bring your features into mtf? Or do you prefer to keep it standalone
>> (@Ed, Sven)?
>>
>> Sven
>> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>>
>>> Hello Sven,
>>>
>>> First you may find the proposal draft here:
>>> http://ebm.batoo.org/index.php/Main_Page
>>>
>>> and, yes I definitely target a cycle with the dependencies resolved both in
>>> the workspace and emf registry, and any change / error flag transitively
>>> will affect the downstream models.
>>>
>>> Frankly I hadn't though about caching all the extension from the registry. I
>>> should add that as an enhancement request.
>>>
>>> Hasan
>>>
>>> Sven Krause wrote:
>>>
>>>
>>>
>>>> Hi Hasan, Sven, Ed,
>>>>
>>>> wouldn't it make sense to have such an background build/gen job not only
>>>> limited to ecore/gen/xtext? The most emf based models are registered
>>>> with its package factory and the potential file extension. So it should
>>>> be easily possible to identify each kind of model of model files within
>>>> the marked projects and launch the generic validate/build build hook for
>>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>>> a special case. PS:the change of a base model might/should trigger the
>>>> dependent model build cycle too.
>>>>
>>>> Sven
>>>>
>>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>>
>>>>
>>>>> Yes, I think it definitely makes sense at some point.
>>>>> Maybe we should work on extracting that functionality during the next
>>>>> release train?
>>>>>
>>>>> Sven
>>>>>
>>>>> Ed Merks schrieb:
>>>>>
>>>>>
>>>>>> Sven,
>>>>>>
>>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>>> of general utility like this makes sense to separate out from Xtext
>>>>>> itself?
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>
>>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>>> genodel:
>>>>>>>> 1) Change the ecore
>>>>>>>> 2) open genmodel
>>>>>>>> 3) Issue generate all
>>>>>>>>
>>>>>>>> and does this with the dependencies considered (validates and
>>>>>>>> generates the dependent models)
>>>>>>>>
>>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>>
>>>>>>>>
>>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>>> builder infraststructure in Xtext.
>>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>>> affected resources, it validates the affected resources and it
>>>>>>> provides two extension points:
>>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>>> affected genmodels and epackages).
>>>>>>>
>>>>>>> I have blogged about the builder infrastructure in general:
>>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>>
>>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>>> the new & noteworthy page.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>>> and
>>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>>> also
>>>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>>>
>>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>>> This one get's a call after each build passed in the
>>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>>>> code generation.
>>>>>>>>>
>>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>>> document
>>>>>>>>> see M5/ProjectBuilder
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hello Sven,
>>>>>>>>>>
>>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>>
>>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>>> development bench?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hasan
>>>>>>>>>>
>>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Hasan,
>>>>>>>>>>>
>>>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Sven
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512845 is a reply to message #512757] Sun, 07 February 2010 21:46 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Sven Krause schrieb:
> Hi Sven,
>
> doesn't put this construct extra effort in allowing trigger builds on
> any model or did use this explicit as filter?

Sorry, I don't understand what you're asking.

Sven

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512846 is a reply to message #512756] Sun, 07 February 2010 21:46 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
See my other reply in this thread.
I think such a functionality belongs to the EMF Index project.

Sven

Sven Krause schrieb:
> Hi Hasan, Sven
>
> we have similar capabilities in the flowr project that became base of
> the new mtf eclipse project. Are you interested to join the project and
> bring your features into mtf? Or do you prefer to keep it standalone
> (@Ed, Sven)?
>
> Sven
> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>> Hello Sven,
>>
>> First you may find the proposal draft here:
>> http://ebm.batoo.org/index.php/Main_Page
>>
>> and, yes I definitely target a cycle with the dependencies resolved both in
>> the workspace and emf registry, and any change / error flag transitively
>> will affect the downstream models.
>>
>> Frankly I hadn't though about caching all the extension from the registry. I
>> should add that as an enhancement request.
>>
>> Hasan
>>
>> Sven Krause wrote:
>>
>>
>>> Hi Hasan, Sven, Ed,
>>>
>>> wouldn't it make sense to have such an background build/gen job not only
>>> limited to ecore/gen/xtext? The most emf based models are registered
>>> with its package factory and the potential file extension. So it should
>>> be easily possible to identify each kind of model of model files within
>>> the marked projects and launch the generic validate/build build hook for
>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>> a special case. PS:the change of a base model might/should trigger the
>>> dependent model build cycle too.
>>>
>>> Sven
>>>
>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>
>>>> Yes, I think it definitely makes sense at some point.
>>>> Maybe we should work on extracting that functionality during the next
>>>> release train?
>>>>
>>>> Sven
>>>>
>>>> Ed Merks schrieb:
>>>>
>>>>> Sven,
>>>>>
>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>> of general utility like this makes sense to separate out from Xtext
>>>>> itself?
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>> genodel:
>>>>>>> 1) Change the ecore
>>>>>>> 2) open genmodel
>>>>>>> 3) Issue generate all
>>>>>>>
>>>>>>> and does this with the dependencies considered (validates and
>>>>>>> generates the dependent models)
>>>>>>>
>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>
>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>> builder infraststructure in Xtext.
>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>> affected resources, it validates the affected resources and it
>>>>>> provides two extension points:
>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>> affected genmodels and epackages).
>>>>>>
>>>>>> I have blogged about the builder infrastructure in general:
>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>
>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>> the new & noteworthy page.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>> and
>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>> also
>>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>>
>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>> This one get's a call after each build passed in the
>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>>> code generation.
>>>>>>>>
>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>> document
>>>>>>>> see M5/ProjectBuilder
>>>>>>>>
>>>>>>>>
>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>
>>>>>>>>> Hello Sven,
>>>>>>>>>
>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>
>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>> development bench?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hasan
>>>>>>>>>
>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Hasan,
>>>>>>>>>>
>>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512854 is a reply to message #512845] Mon, 08 February 2010 03:14 Go to previous messageGo to next message
Sven Krause is currently offline Sven Krause
Messages: 119
Registered: July 2009
Senior Member
Hi Sven,

Sorry for confusing you. I meant: the user needs to register its model
explicite at the service to be handled during the build. The question
was: is this extra step a feature (the user needs to know what he is
doing) or would it be more convenient to build all known models per
default? Are you afraid that the build performance decreases when
bulding/validating/indexing/whatever all models within the scope?

Sven

Am 08.02.2010 07:57, schrieb Sven Efftinge:
> Sven Krause schrieb:
>> Hi Sven,
>>
>> doesn't put this construct extra effort in allowing trigger builds on
>> any model or did use this explicit as filter?
>
> Sorry, I don't understand what you're asking.
>
> Sven
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512877 is a reply to message #512854] Mon, 08 February 2010 04:24 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
One doesn't register by model, but by language (ie resource factory).
However, the resource factory alone does not provide the needed services
to index and validate resources. That's why we have introduced an
additional registry/extension point.
Also this decouples building and indexing from existence of a
resource.factory. Which as you suspected can be a performance problem.
(We actually already faced such a situation in a real project we're
supporting)

Cheers,
Sven

Sven Krause schrieb:
> Hi Sven,
>
> Sorry for confusing you. I meant: the user needs to register its model
> explicite at the service to be handled during the build. The question
> was: is this extra step a feature (the user needs to know what he is
> doing) or would it be more convenient to build all known models per
> default? Are you afraid that the build performance decreases when
> bulding/validating/indexing/whatever all models within the scope?
>
> Sven
>
> Am 08.02.2010 07:57, schrieb Sven Efftinge:
>> Sven Krause schrieb:
>>> Hi Sven,
>>>
>>> doesn't put this construct extra effort in allowing trigger builds on
>>> any model or did use this explicit as filter?
>>
>> Sorry, I don't understand what you're asking.
>>
>> Sven
>>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512929 is a reply to message #512846] Mon, 08 February 2010 06:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Sven,

Yes, I'd prefer to see the "generic" indexing be part of the index
project. Do you think support for triggered activities such as builds
or validation should be part of the index project as well?


Sven Efftinge wrote:
> See my other reply in this thread.
> I think such a functionality belongs to the EMF Index project.
>
> Sven
>
> Sven Krause schrieb:
>> Hi Hasan, Sven
>>
>> we have similar capabilities in the flowr project that became base of
>> the new mtf eclipse project. Are you interested to join the project and
>> bring your features into mtf? Or do you prefer to keep it standalone
>> (@Ed, Sven)?
>>
>> Sven
>> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>>> Hello Sven,
>>>
>>> First you may find the proposal draft here:
>>> http://ebm.batoo.org/index.php/Main_Page
>>>
>>> and, yes I definitely target a cycle with the dependencies resolved
>>> both in the workspace and emf registry, and any change / error flag
>>> transitively will affect the downstream models.
>>>
>>> Frankly I hadn't though about caching all the extension from the
>>> registry. I should add that as an enhancement request.
>>>
>>> Hasan
>>>
>>> Sven Krause wrote:
>>>
>>>
>>>> Hi Hasan, Sven, Ed,
>>>>
>>>> wouldn't it make sense to have such an background build/gen job not
>>>> only
>>>> limited to ecore/gen/xtext? The most emf based models are registered
>>>> with its package factory and the potential file extension. So it
>>>> should
>>>> be easily possible to identify each kind of model of model files
>>>> within
>>>> the marked projects and launch the generic validate/build build
>>>> hook for
>>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is
>>>> just
>>>> a special case. PS:the change of a base model might/should trigger the
>>>> dependent model build cycle too.
>>>>
>>>> Sven
>>>>
>>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>>
>>>>> Yes, I think it definitely makes sense at some point.
>>>>> Maybe we should work on extracting that functionality during the next
>>>>> release train?
>>>>>
>>>>> Sven
>>>>>
>>>>> Ed Merks schrieb:
>>>>>
>>>>>> Sven,
>>>>>>
>>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>>> of general utility like this makes sense to separate out from Xtext
>>>>>> itself?
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>>> genodel:
>>>>>>>> 1) Change the ecore
>>>>>>>> 2) open genmodel
>>>>>>>> 3) Issue generate all
>>>>>>>>
>>>>>>>> and does this with the dependencies considered (validates and
>>>>>>>> generates the dependent models)
>>>>>>>>
>>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>>
>>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>>> builder infraststructure in Xtext.
>>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>>> affected resources, it validates the affected resources and it
>>>>>>> provides two extension points:
>>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>>> affected genmodels and epackages).
>>>>>>>
>>>>>>> I have blogged about the builder infrastructure in general:
>>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>>
>>>>>>>
>>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>>> the new & noteworthy page.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>>> a) implementing and registering IResourceServiceProvider for
>>>>>>>>> ecore
>>>>>>>>> and
>>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>>> also
>>>>>>>>> provides the needed hook to compute the transitive hull of
>>>>>>>>> changes.
>>>>>>>>>
>>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>>> This one get's a call after each build passed in the
>>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to
>>>>>>>>> trigger
>>>>>>>>> code generation.
>>>>>>>>>
>>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>>> document
>>>>>>>>> see M5/ProjectBuilder
>>>>>>>>>
>>>>>>>>>
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>>
>>>>>>>>>> Hello Sven,
>>>>>>>>>>
>>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>>
>>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>>> development bench?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hasan
>>>>>>>>>>
>>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Hasan,
>>>>>>>>>>>
>>>>>>>>>>> how is this idea related to Xtext's builder infrastructure
>>>>>>>>>>> and EMF
>>>>>>>>>>> index? It seems to be a perfect match for what you want to
>>>>>>>>>>> achieve.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Sven
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512966 is a reply to message #512929] Mon, 08 February 2010 08:00 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Sven,
>
> Yes, I'd prefer to see the "generic" indexing be part of the index
> project. Do you think support for triggered activities such as builds
> or validation should be part of the index project as well?

Yes, I think so, because it is technically hard to separate between
these things. A central mechanism which keeps the workspace in sync with
the index, has everything we need to do validation and further post
processing (like triggering code generation).

The EMF index should of course *not* provide language specific
implementations. For instance a GenModel execution for changes in ecore
or genmodels, like Hassan proposed, clearly belongs elsewhere (e.g.
EcoreTools).

So far, all that stuff is located in Xtext's repository.

Sven

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512980 is a reply to message #512966] Mon, 08 February 2010 08:51 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Sven & Ed,

I have posted the beta release of EBM. I would appricate you comments and
reviews.

Having not aware of the EMF Index project, I developed an internal builder
state and dependency model (SDK has the code). We should revise that part if
necessary, by the way what is the state of EMF Index project?

Hasan

Sven Efftinge wrote:

> Ed Merks schrieb:
>> Sven,
>>
>> Yes, I'd prefer to see the "generic" indexing be part of the index
>> project. Do you think support for triggered activities such as builds
>> or validation should be part of the index project as well?
>
> Yes, I think so, because it is technically hard to separate between
> these things. A central mechanism which keeps the workspace in sync with
> the index, has everything we need to do validation and further post
> processing (like triggering code generation).
>
> The EMF index should of course *not* provide language specific
> implementations. For instance a GenModel execution for changes in ecore
> or genmodels, like Hassan proposed, clearly belongs elsewhere (e.g.
> EcoreTools).
>
> So far, all that stuff is located in Xtext's repository.
>
> Sven
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #513128 is a reply to message #512774] Mon, 08 February 2010 14:14 Go to previous messageGo to next message
Yves YANG is currently offline Yves YANG
Messages: 687
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_0036_01CAA922.83FABBB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It seems EGF has this capability. It is really a task orchestration =
system. We are investigating to use it in PMF.

Regards
Yves YANG
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:hkmj9d$kms$2@build.eclipse.org...
A separate builder project seems like a good thing. It seems closely =
related to the Sphinx proposal as well, so it might make sense for it to =
be part of that too...

Sven Krause wrote:=20
Hi Hasan, Sven

we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?

Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
Hello Sven,

First you may find the proposal draft here:
http://ebm.batoo.org/index.php/Main_Page

and, yes I definitely target a cycle with the dependencies resolved both =
in=20
the workspace and emf registry, and any change / error flag transitively =

will affect the downstream models.

Frankly I hadn't though about caching all the extension from the =
registry. I=20
should add that as an enhancement request.

Hasan

Sven Krause wrote:

=20
Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:
=20
Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:
=20
Sven,

This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?
=20
Sven Efftinge wrote:
=20
Hasan Ceylan schrieb:
=20
The aim of EMF Builder is to validate and generate java =
artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and
generates the dependent models)

XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
=20
No, I didn't meant anything MWE related. I was talking of =
the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).

I have blogged about the builder infrastructure in general:
http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html

The participant hook had been introduced with M5 and is demoed on
the new & noteworthy page.

Cheers,
Sven


=20
Hasan

Sven Efftinge wrote:

=20
With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&n
document
see M5/ProjectBuilder

=20
=
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)=

=20
Sven

Hasan Ceylan schrieb:
=20
Hello Sven,

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a
development bench?

Regards,
Hasan

Sven Efftinge wrote:

=20
Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven

=20
<SNIP>

=20
=20
=20
=20
=20

------=_NextPart_000_0036_01CAA922.83FABBB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff text=3D#000000>
<DIV><FONT size=3D2 face=3DArial>It seems EGF has this capability. It is =
really a=20
task orchestration system.&nbsp;We are investigating to use it in=20
PMF.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2 face=3DArial>Regards</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>Yves YANG</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" &lt;<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>&gt; wrote in =
message=20
<A=20
=
href=3D"news:hkmj9d$kms$2@build.eclipse.org">news:hkmj9d$kms$2@build.ecli=
pse.org</A>...</DIV>A=20
separate builder project seems like a good thing.&nbsp; It seems =
closely=20
related to the Sphinx proposal as well, so it might make sense for it =
to be=20
part of that too...<BR><BR>Sven Krause wrote:=20
<BLOCKQUOTE cite=3Dmid:hkm1dc$1js$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hi Hasan, Sven

we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?

Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello Sven,

First you may find the proposal draft here:
<A class=3Dmoz-txt-link-freetext =
href=3D"http://ebm.batoo.org/index.php/Main_Page">http://ebm.batoo.org/in=
dex.php/Main_Page</A>

and, yes I definitely target a cycle with the dependencies resolved both =
in=20
the workspace and emf registry, and any change / error flag transitively =

will affect the downstream models.

Frankly I hadn't though about caching all the extension from the =
registry. I=20
should add that as an enhancement request.

Hasan

Sven Krause wrote:

=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Yes, I think it =
definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Sven,

This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?
=20
Sven Efftinge wrote:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hasan Ceylan =
schrieb:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">The aim of EMF =
Builder is to validate and generate java artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and
generates the dependent models)

XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
=20
</PRE></BLOCKQUOTE><PRE wrap=3D"">No, I didn't meant =
anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).

I have blogged about the builder infrastructure in general:
<A class=3Dmoz-txt-link-freetext =
href=3D" http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture=
..html"> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.=
html</A>

The participant hook had been introduced with M5 and is demoed on
the new &amp; noteworthy page.

Cheers,
Sven


=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hasan

Sven Efftinge wrote:

=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">With Xtext M5 =
it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&amp;n
document
see M5/ProjectBuilder

=20
=
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BLOCKQUOTE></=
BLOCKQUOTE><PRE wrap=3D"">(<A class=3Dmoz-txt-link-freetext =
href=3D" http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not ewort=
hy.php"> http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not ewort=
hy.php</A>)
=20
</PRE>
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Sven

Hasan Ceylan schrieb:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello Sven,

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a
development bench?

Regards,
Hasan

Sven Efftinge wrote:

=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven

=20
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">&lt;SNIP&gt;

=20
</PRE></BLOCKQUOTE><PRE wrap=3D""> =20
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""> =20
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""> =20
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0036_01CAA922.83FABBB0--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618583 is a reply to message #511333] Mon, 01 February 2010 07:46 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad Varnica
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
EMF is a great project but ............
Nice post Hassan.

Vlad,
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618585 is a reply to message #511333] Mon, 01 February 2010 09:10 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Ed,

Thanks for sharing you comments. I will surely take a look at referenced
wizard / builder.

I think the project will handle situations like this well enough since:
1) It has built-in support for dependency chain, meaning only the affected
models in the change chain is marked for validation & generation
2) It is not a must, to have the nature to have an EMF project, since you
can add / remove the nature by project->right click
3) Builder triggers on save rather then "working-copy".
4) This can further be improved by adding a grace-period and / or max-depth
configuration. Meaning, consecutive changes to models within a time window
will gather changes and start the *real* build only after the grace period
expires. Reaching of *Max-depth* can place a mark on the status bar as well
as putting validation markers on the affected-but-yet-processed resources.
Clicking on the status bar notification or quick fix on the markers, can
trigger partition or deal with the rest of the process.
5) An unavoidable requirement of working with (even for XX number of
projects in a single workspace)is, whatever the chosen way of dealing with
EMF validation and build, eventually you have to generate. When this happens
EBM's promise is to relieve the workspace to the extent possible, with smart
dependency tracking and putting resource-locks on only the provisional
extension of the build process of the dirty models. This means, putting lock
only on the list of models in the dirty models and java package namespace of
the gemodels.
6) One of the nice features of the workspace resource locks is, say you are
working on a chanin of models. After some editing, you save your work, which
is where the builder kicks in. It certainly works in the background and as
long as you do not save an editor in the affected resources (chain of
dependency and genmodel java artifacts), further save blocks the UI if the
build is still going on. Here the user has option which includes
i) revertion the save request, which will go back to the editing domain
ii) Can halt the builder and postpone the build process altogether to a
futher time
7) Since the validation and generation do not modify the model resources
this has minimal impact on post-build dirt-editor merge.


One of the interesting outcome of my test with a sample workspace with 5
interdependent ecore + genmodel is while normally it takes about few
secconds to generate a genmodel, the whole process takes 2 times of that
time. I guess, this is due to, CPU caching and less processing and stack
operation due to less resortion to UI both in terms of painting and going
all the way down to OS UI bindings.

I am well aware of the cost of nature/builder integration for a relatively
large EMF workspace. But this is / can become a -no-longer-a-thread by
i) Smart handling of the models (Hey after all we arfe dealing with the
models right, which is exactly for this very reason)
2) Computers and processors evolved drastically since the introduction of
EMF. (that is about 8-10x) [1] [2]

Regards,
Hasan

[1] http://www.cpubenchmark.net/high_end_cpus.html
[2] http://www.cpubenchmark.net/low_end_cpus.html


Ed Merks wrote:

> Hasan,
>
> This posting only has your CV, but I found it in one of your other cross
> posts.
>
> I think that the extremely well hidden generator wizard addresses many
> of these concerns though there's certainly room for improvements:
>
> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
generate-my-28.html
>
> 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,
>>>
>>>
>>
>>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618970 is a reply to message #511391] Thu, 04 February 2010 07:20 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven

Hasan Ceylan schrieb:
> Hello Ed,
>
> Thanks for sharing you comments. I will surely take a look at referenced
> wizard / builder.
>
> I think the project will handle situations like this well enough since:
> 1) It has built-in support for dependency chain, meaning only the affected
> models in the change chain is marked for validation & generation
> 2) It is not a must, to have the nature to have an EMF project, since you
> can add / remove the nature by project->right click
> 3) Builder triggers on save rather then "working-copy".
> 4) This can further be improved by adding a grace-period and / or max-depth
> configuration. Meaning, consecutive changes to models within a time window
> will gather changes and start the *real* build only after the grace period
> expires. Reaching of *Max-depth* can place a mark on the status bar as well
> as putting validation markers on the affected-but-yet-processed resources.
> Clicking on the status bar notification or quick fix on the markers, can
> trigger partition or deal with the rest of the process.
> 5) An unavoidable requirement of working with (even for XX number of
> projects in a single workspace)is, whatever the chosen way of dealing with
> EMF validation and build, eventually you have to generate. When this happens
> EBM's promise is to relieve the workspace to the extent possible, with smart
> dependency tracking and putting resource-locks on only the provisional
> extension of the build process of the dirty models. This means, putting lock
> only on the list of models in the dirty models and java package namespace of
> the gemodels.
> 6) One of the nice features of the workspace resource locks is, say you are
> working on a chanin of models. After some editing, you save your work, which
> is where the builder kicks in. It certainly works in the background and as
> long as you do not save an editor in the affected resources (chain of
> dependency and genmodel java artifacts), further save blocks the UI if the
> build is still going on. Here the user has option which includes
> i) revertion the save request, which will go back to the editing domain
> ii) Can halt the builder and postpone the build process altogether to a
> futher time
> 7) Since the validation and generation do not modify the model resources
> this has minimal impact on post-build dirt-editor merge.
>
>
> One of the interesting outcome of my test with a sample workspace with 5
> interdependent ecore + genmodel is while normally it takes about few
> secconds to generate a genmodel, the whole process takes 2 times of that
> time. I guess, this is due to, CPU caching and less processing and stack
> operation due to less resortion to UI both in terms of painting and going
> all the way down to OS UI bindings.
>
> I am well aware of the cost of nature/builder integration for a relatively
> large EMF workspace. But this is / can become a -no-longer-a-thread by
> i) Smart handling of the models (Hey after all we arfe dealing with the
> models right, which is exactly for this very reason)
> 2) Computers and processors evolved drastically since the introduction of
> EMF. (that is about 8-10x) [1] [2]
>
> Regards,
> Hasan
>
> [1] http://www.cpubenchmark.net/high_end_cpus.html
> [2] http://www.cpubenchmark.net/low_end_cpus.html
>
>
> Ed Merks wrote:
>
>> Hasan,
>>
>> This posting only has your CV, but I found it in one of your other cross
>> posts.
>>
>> I think that the extremely well hidden generator wizard addresses many
>> of these concerns though there's certainly room for improvements:
>>
>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
> generate-my-28.html
>> 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,
>>>>
>>>>
>>>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618974 is a reply to message #512211] Fri, 05 February 2010 03:53 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Sven,

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a development bench?

Regards,
Hasan

Sven Efftinge wrote:

> Hi Hasan,
>
> how is this idea related to Xtext's builder infrastructure and EMF
> index? It seems to be a perfect match for what you want to achieve.
>
> Cheers,
> Sven
>
> Hasan Ceylan schrieb:
>> Hello Ed,
>>
>> Thanks for sharing you comments. I will surely take a look at referenced
>> wizard / builder.
>>
>> I think the project will handle situations like this well enough since:
>> 1) It has built-in support for dependency chain, meaning only the
>> affected models in the change chain is marked for validation & generation
>> 2) It is not a must, to have the nature to have an EMF project, since you
>> can add / remove the nature by project->right click
>> 3) Builder triggers on save rather then "working-copy".
>> 4) This can further be improved by adding a grace-period and / or
>> max-depth configuration. Meaning, consecutive changes to models within a
>> time window will gather changes and start the *real* build only after the
>> grace period expires. Reaching of *Max-depth* can place a mark on the
>> status bar as well as putting validation markers on the
>> affected-but-yet-processed resources. Clicking on the status bar
>> notification or quick fix on the markers, can trigger partition or deal
>> with the rest of the process. 5) An unavoidable requirement of working
>> with (even for XX number of projects in a single workspace)is, whatever
>> the chosen way of dealing with EMF validation and build, eventually you
>> have to generate. When this happens EBM's promise is to relieve the
>> workspace to the extent possible, with smart dependency tracking and
>> putting resource-locks on only the provisional extension of the build
>> process of the dirty models. This means, putting lock only on the list of
>> models in the dirty models and java package namespace of the gemodels.
>> 6) One of the nice features of the workspace resource locks is, say you
>> are working on a chanin of models. After some editing, you save your
>> work, which is where the builder kicks in. It certainly works in the
>> background and as long as you do not save an editor in the affected
>> resources (chain of dependency and genmodel java artifacts), further save
>> blocks the UI if the build is still going on. Here the user has option
>> which includes i) revertion the save request, which will go back to the
>> editing domain ii) Can halt the builder and postpone the build process
>> altogether to a futher time
>> 7) Since the validation and generation do not modify the model resources
>> this has minimal impact on post-build dirt-editor merge.
>>
>>
>> One of the interesting outcome of my test with a sample workspace with 5
>> interdependent ecore + genmodel is while normally it takes about few
>> secconds to generate a genmodel, the whole process takes 2 times of that
>> time. I guess, this is due to, CPU caching and less processing and stack
>> operation due to less resortion to UI both in terms of painting and going
>> all the way down to OS UI bindings.
>>
>> I am well aware of the cost of nature/builder integration for a
>> relatively large EMF workspace. But this is / can become a
>> -no-longer-a-thread by i) Smart handling of the models (Hey after all we
>> arfe dealing with the models right, which is exactly for this very
>> reason) 2) Computers and processors evolved drastically since the
>> introduction of EMF. (that is about 8-10x) [1] [2]
>>
>> Regards,
>> Hasan
>>
>> [1] http://www.cpubenchmark.net/high_end_cpus.html
>> [2] http://www.cpubenchmark.net/low_end_cpus.html
>>
>>
>> Ed Merks wrote:
>>
>>> Hasan,
>>>
>>> This posting only has your CV, but I found it in one of your other cross
>>> posts.
>>>
>>> I think that the extremely well hidden generator wizard addresses many
>>> of these concerns though there's certainly room for improvements:
>>>
>>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
>> generate-my-28.html
>>> 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,
>>>>>
>>>>>
>>>>
>>
>
>

--

Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647


From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."

--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618977 is a reply to message #512459] Fri, 05 February 2010 04:20 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore and
genmodel. This makes sure that ecore and genmodel are indexed. It also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&n document
see M5/ProjectBuilder
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)

Sven

Hasan Ceylan schrieb:
> Hello Sven,
>
> Would love to test with Xtext + EMF Index bench.
>
> Would you be so kind to give me directions to set up a development bench?
>
> Regards,
> Hasan
>
> Sven Efftinge wrote:
>
>> Hi Hasan,
>>
>> how is this idea related to Xtext's builder infrastructure and EMF
>> index? It seems to be a perfect match for what you want to achieve.
>>
>> Cheers,
>> Sven
>>
>> Hasan Ceylan schrieb:
>>> Hello Ed,
>>>
>>> Thanks for sharing you comments. I will surely take a look at referenced
>>> wizard / builder.
>>>
>>> I think the project will handle situations like this well enough since:
>>> 1) It has built-in support for dependency chain, meaning only the
>>> affected models in the change chain is marked for validation & generation
>>> 2) It is not a must, to have the nature to have an EMF project, since you
>>> can add / remove the nature by project->right click
>>> 3) Builder triggers on save rather then "working-copy".
>>> 4) This can further be improved by adding a grace-period and / or
>>> max-depth configuration. Meaning, consecutive changes to models within a
>>> time window will gather changes and start the *real* build only after the
>>> grace period expires. Reaching of *Max-depth* can place a mark on the
>>> status bar as well as putting validation markers on the
>>> affected-but-yet-processed resources. Clicking on the status bar
>>> notification or quick fix on the markers, can trigger partition or deal
>>> with the rest of the process. 5) An unavoidable requirement of working
>>> with (even for XX number of projects in a single workspace)is, whatever
>>> the chosen way of dealing with EMF validation and build, eventually you
>>> have to generate. When this happens EBM's promise is to relieve the
>>> workspace to the extent possible, with smart dependency tracking and
>>> putting resource-locks on only the provisional extension of the build
>>> process of the dirty models. This means, putting lock only on the list of
>>> models in the dirty models and java package namespace of the gemodels.
>>> 6) One of the nice features of the workspace resource locks is, say you
>>> are working on a chanin of models. After some editing, you save your
>>> work, which is where the builder kicks in. It certainly works in the
>>> background and as long as you do not save an editor in the affected
>>> resources (chain of dependency and genmodel java artifacts), further save
>>> blocks the UI if the build is still going on. Here the user has option
>>> which includes i) revertion the save request, which will go back to the
>>> editing domain ii) Can halt the builder and postpone the build process
>>> altogether to a futher time
>>> 7) Since the validation and generation do not modify the model resources
>>> this has minimal impact on post-build dirt-editor merge.
>>>
>>>
>>> One of the interesting outcome of my test with a sample workspace with 5
>>> interdependent ecore + genmodel is while normally it takes about few
>>> secconds to generate a genmodel, the whole process takes 2 times of that
>>> time. I guess, this is due to, CPU caching and less processing and stack
>>> operation due to less resortion to UI both in terms of painting and going
>>> all the way down to OS UI bindings.
>>>
>>> I am well aware of the cost of nature/builder integration for a
>>> relatively large EMF workspace. But this is / can become a
>>> -no-longer-a-thread by i) Smart handling of the models (Hey after all we
>>> arfe dealing with the models right, which is exactly for this very
>>> reason) 2) Computers and processors evolved drastically since the
>>> introduction of EMF. (that is about 8-10x) [1] [2]
>>>
>>> Regards,
>>> Hasan
>>>
>>> [1] http://www.cpubenchmark.net/high_end_cpus.html
>>> [2] http://www.cpubenchmark.net/low_end_cpus.html
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Hasan,
>>>>
>>>> This posting only has your CV, but I found it in one of your other cross
>>>> posts.
>>>>
>>>> I think that the extremely well hidden generator wizard addresses many
>>>> of these concerns though there's certainly room for improvements:
>>>>
>>>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
>>> generate-my-28.html
>>>> 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,
>>>>>>
>>>>>>
>>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618979 is a reply to message #512479] Fri, 05 February 2010 04:54 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Sven,

I'm a bit confused.

The aim of EMF Builder is to validate and generate java artifacts on ecore,
xmi and genmodel based on changes on the resources. Basically automates what
you would do when you have an ecore and a genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and generates the
dependent models)

XText does this automatically with the mwe runner. Are you suggesting
integrating the xtext mwe into EMFBuilder so that the generation is
automated? I just couldn't get it, sorry

Hasan

Sven Efftinge wrote:

>
> With Xtext M5 it is basically a matter of
> a) implementing and registering IResourceServiceProvider for ecore and
> genmodel. This makes sure that ecore and genmodel are indexed. It also
> provides the needed hook to compute the transitive hull of changes.
>
> b) implementing and registering IBuildParticipant.
> This one get's a call after each build passed in the
> IResourceDescription.Deltas. Based on that you'll be able to trigger
> code generation.
>
> There's a short video demonstrating the second hook in our n&n document
> see M5/ProjectBuilder
> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>
> Sven
>
> Hasan Ceylan schrieb:
>> Hello Sven,
>>
>> Would love to test with Xtext + EMF Index bench.
>>
>> Would you be so kind to give me directions to set up a development bench?
>>
>> Regards,
>> Hasan
>>
>> Sven Efftinge wrote:
>>
>>> Hi Hasan,
>>>
>>> how is this idea related to Xtext's builder infrastructure and EMF
>>> index? It seems to be a perfect match for what you want to achieve.
>>>
>>> Cheers,
>>> Sven
>>>
<SNIP>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618982 is a reply to message #618979] Fri, 05 February 2010 05:09 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Hasan Ceylan schrieb:
> The aim of EMF Builder is to validate and generate java artifacts on ecore,
> xmi and genmodel based on changes on the resources. Basically automates what
> you would do when you have an ecore and a genodel:
> 1) Change the ecore
> 2) open genmodel
> 3) Issue generate all
>
> and does this with the dependencies considered (validates and generates the
> dependent models)
>
> XText does this automatically with the mwe runner. Are you suggesting
> integrating the xtext mwe into EMFBuilder so that the generation is
> automated? I just couldn't get it, sorry

No, I didn't meant anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it provides
two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based on
the outcome of a build. (E.g. to start the generation of any affected
genmodels and epackages).

I have blogged about the builder infrastructure in general:
http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html

The participant hook had been introduced with M5 and is demoed on the
new & noteworthy page.

Cheers,
Sven


>
> Hasan
>
> Sven Efftinge wrote:
>
>> With Xtext M5 it is basically a matter of
>> a) implementing and registering IResourceServiceProvider for ecore and
>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>> provides the needed hook to compute the transitive hull of changes.
>>
>> b) implementing and registering IBuildParticipant.
>> This one get's a call after each build passed in the
>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>> code generation.
>>
>> There's a short video demonstrating the second hook in our n&n document
>> see M5/ProjectBuilder
>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>
>> Sven
>>
>> Hasan Ceylan schrieb:
>>> Hello Sven,
>>>
>>> Would love to test with Xtext + EMF Index bench.
>>>
>>> Would you be so kind to give me directions to set up a development bench?
>>>
>>> Regards,
>>> Hasan
>>>
>>> Sven Efftinge wrote:
>>>
>>>> Hi Hasan,
>>>>
>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
> <SNIP>
>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618985 is a reply to message #618982] Fri, 05 February 2010 06:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Sven,

This sounds cool too, and definitely related. I wonder if something of
general utility like this makes sense to separate out from Xtext itself?

Sven Efftinge wrote:
> Hasan Ceylan schrieb:
>> The aim of EMF Builder is to validate and generate java artifacts on
>> ecore, xmi and genmodel based on changes on the resources. Basically
>> automates what you would do when you have an ecore and a genodel:
>> 1) Change the ecore
>> 2) open genmodel
>> 3) Issue generate all
>>
>> and does this with the dependencies considered (validates and
>> generates the dependent models)
>>
>> XText does this automatically with the mwe runner. Are you suggesting
>> integrating the xtext mwe into EMFBuilder so that the generation is
>> automated? I just couldn't get it, sorry
>
> No, I didn't meant anything MWE related. I was talking of the new
> builder infraststructure in Xtext.
> It is just exactly what you have in mind. It listenes on resource
> changes (is triggered on save), it computes the transtive hull of
> affected resources, it validates the affected resources and it
> provides two extension points:
> 1) one to register EMF-based languages (they don't have to be Xtext
> languages) (e.g. *.ecore, *.genmodel)
> 2) one to register participants, which can do arbitrary work based on
> the outcome of a build. (E.g. to start the generation of any affected
> genmodels and epackages).
>
> I have blogged about the builder infrastructure in general:
> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>
> The participant hook had been introduced with M5 and is demoed on the
> new & noteworthy page.
>
> Cheers,
> Sven
>
>
>>
>> Hasan
>>
>> Sven Efftinge wrote:
>>
>>> With Xtext M5 it is basically a matter of
>>> a) implementing and registering IResourceServiceProvider for ecore and
>>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>>> provides the needed hook to compute the transitive hull of changes.
>>>
>>> b) implementing and registering IBuildParticipant.
>>> This one get's a call after each build passed in the
>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>> code generation.
>>>
>>> There's a short video demonstrating the second hook in our n&n document
>>> see M5/ProjectBuilder
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>> Sven
>>>
>>> Hasan Ceylan schrieb:
>>>> Hello Sven,
>>>>
>>>> Would love to test with Xtext + EMF Index bench.
>>>>
>>>> Would you be so kind to give me directions to set up a development
>>>> bench?
>>>>
>>>> Regards,
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hi Hasan,
>>>>>
>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>> <SNIP>
>>
>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618988 is a reply to message #618985] Fri, 05 February 2010 10:01 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:
> Sven,
>
> This sounds cool too, and definitely related. I wonder if something of
> general utility like this makes sense to separate out from Xtext itself?
>
> Sven Efftinge wrote:
>> Hasan Ceylan schrieb:
>>> The aim of EMF Builder is to validate and generate java artifacts on
>>> ecore, xmi and genmodel based on changes on the resources. Basically
>>> automates what you would do when you have an ecore and a genodel:
>>> 1) Change the ecore
>>> 2) open genmodel
>>> 3) Issue generate all
>>>
>>> and does this with the dependencies considered (validates and
>>> generates the dependent models)
>>>
>>> XText does this automatically with the mwe runner. Are you suggesting
>>> integrating the xtext mwe into EMFBuilder so that the generation is
>>> automated? I just couldn't get it, sorry
>>
>> No, I didn't meant anything MWE related. I was talking of the new
>> builder infraststructure in Xtext.
>> It is just exactly what you have in mind. It listenes on resource
>> changes (is triggered on save), it computes the transtive hull of
>> affected resources, it validates the affected resources and it
>> provides two extension points:
>> 1) one to register EMF-based languages (they don't have to be Xtext
>> languages) (e.g. *.ecore, *.genmodel)
>> 2) one to register participants, which can do arbitrary work based on
>> the outcome of a build. (E.g. to start the generation of any affected
>> genmodels and epackages).
>>
>> I have blogged about the builder infrastructure in general:
>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>
>> The participant hook had been introduced with M5 and is demoed on the
>> new & noteworthy page.
>>
>> Cheers,
>> Sven
>>
>>
>>>
>>> Hasan
>>>
>>> Sven Efftinge wrote:
>>>
>>>> With Xtext M5 it is basically a matter of
>>>> a) implementing and registering IResourceServiceProvider for ecore and
>>>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>>>> provides the needed hook to compute the transitive hull of changes.
>>>>
>>>> b) implementing and registering IBuildParticipant.
>>>> This one get's a call after each build passed in the
>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>> code generation.
>>>>
>>>> There's a short video demonstrating the second hook in our n&n document
>>>> see M5/ProjectBuilder
>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>
>>>>
>>>> Sven
>>>>
>>>> Hasan Ceylan schrieb:
>>>>> Hello Sven,
>>>>>
>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>
>>>>> Would you be so kind to give me directions to set up a development
>>>>> bench?
>>>>>
>>>>> Regards,
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hi Hasan,
>>>>>>
>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>> <SNIP>
>>>
>>
>>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618991 is a reply to message #512597] Sat, 06 February 2010 12:33 Go to previous messageGo to next message
Sven Krause is currently offline Sven Krause
Messages: 64
Registered: July 2009
Member
Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:
> Yes, I think it definitely makes sense at some point.
> Maybe we should work on extracting that functionality during the next
> release train?
>
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> This sounds cool too, and definitely related. I wonder if something
>> of general utility like this makes sense to separate out from Xtext
>> itself?
>>
>> Sven Efftinge wrote:
>>> Hasan Ceylan schrieb:
>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>> Basically automates what you would do when you have an ecore and a
>>>> genodel:
>>>> 1) Change the ecore
>>>> 2) open genmodel
>>>> 3) Issue generate all
>>>>
>>>> and does this with the dependencies considered (validates and
>>>> generates the dependent models)
>>>>
>>>> XText does this automatically with the mwe runner. Are you
>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>> generation is automated? I just couldn't get it, sorry
>>>
>>> No, I didn't meant anything MWE related. I was talking of the new
>>> builder infraststructure in Xtext.
>>> It is just exactly what you have in mind. It listenes on resource
>>> changes (is triggered on save), it computes the transtive hull of
>>> affected resources, it validates the affected resources and it
>>> provides two extension points:
>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>> languages) (e.g. *.ecore, *.genmodel)
>>> 2) one to register participants, which can do arbitrary work based
>>> on the outcome of a build. (E.g. to start the generation of any
>>> affected genmodels and epackages).
>>>
>>> I have blogged about the builder infrastructure in general:
>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>
>>> The participant hook had been introduced with M5 and is demoed on
>>> the new & noteworthy page.
>>>
>>> Cheers,
>>> Sven
>>>
>>>
>>>>
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> With Xtext M5 it is basically a matter of
>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>> and
>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>> also
>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>
>>>>> b) implementing and registering IBuildParticipant.
>>>>> This one get's a call after each build passed in the
>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>> code generation.
>>>>>
>>>>> There's a short video demonstrating the second hook in our n&n
>>>>> document
>>>>> see M5/ProjectBuilder
>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>
>>>>>
>>>>> Sven
>>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>> Hello Sven,
>>>>>>
>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>
>>>>>> Would you be so kind to give me directions to set up a
>>>>>> development bench?
>>>>>>
>>>>>> Regards,
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hi Hasan,
>>>>>>>
>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>> <SNIP>
>>>>
>>>
>>>
>
>
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618993 is a reply to message #512710] Sat, 06 February 2010 12:56 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080709090205030609010102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sven,

What the other Sven described sounded quite general along the lines of
what you're suggesting. It would certainly be good in such a framework
to make a validation cycle trivial to enable, i.e., just an extension
with a generic reusable validator trigger.


Sven Krause wrote:
> Hi Hasan, Sven, Ed,
>
> wouldn't it make sense to have such an background build/gen job not only
> limited to ecore/gen/xtext? The most emf based models are registered
> with its package factory and the potential file extension. So it should
> be easily possible to identify each kind of model of model files within
> the marked projects and launch the generic validate/build build hook for
> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
> a special case. PS:the change of a base model might/should trigger the
> dependent model build cycle too.
>
> Sven
>
> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>
>> Yes, I think it definitely makes sense at some point.
>> Maybe we should work on extracting that functionality during the next
>> release train?
>>
>> Sven
>>
>> Ed Merks schrieb:
>>
>>> Sven,
>>>
>>> This sounds cool too, and definitely related. I wonder if something
>>> of general utility like this makes sense to separate out from Xtext
>>> itself?
>>>
>>> Sven Efftinge wrote:
>>>
>>>> Hasan Ceylan schrieb:
>>>>
>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>> Basically automates what you would do when you have an ecore and a
>>>>> genodel:
>>>>> 1) Change the ecore
>>>>> 2) open genmodel
>>>>> 3) Issue generate all
>>>>>
>>>>> and does this with the dependencies considered (validates and
>>>>> generates the dependent models)
>>>>>
>>>>> XText does this automatically with the mwe runner. Are you
>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>> generation is automated? I just couldn't get it, sorry
>>>>>
>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>> builder infraststructure in Xtext.
>>>> It is just exactly what you have in mind. It listenes on resource
>>>> changes (is triggered on save), it computes the transtive hull of
>>>> affected resources, it validates the affected resources and it
>>>> provides two extension points:
>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>> languages) (e.g. *.ecore, *.genmodel)
>>>> 2) one to register participants, which can do arbitrary work based
>>>> on the outcome of a build. (E.g. to start the generation of any
>>>> affected genmodels and epackages).
>>>>
>>>> I have blogged about the builder infrastructure in general:
>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>
>>>> The participant hook had been introduced with M5 and is demoed on
>>>> the new & noteworthy page.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
>>>>
>>>>
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>
>>>>>> With Xtext M5 it is basically a matter of
>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>> and
>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>> also
>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>
>>>>>> b) implementing and registering IBuildParticipant.
>>>>>> This one get's a call after each build passed in the
>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>> code generation.
>>>>>>
>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>> document
>>>>>> see M5/ProjectBuilder
>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>
>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>> development bench?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Hasan,
>>>>>>>>
>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sven
>>>>>>>>
>>>>>>>>
>>>>> <SNIP>
>>>>>
>>>>>
>>>>
>>
>
>

--------------080709090205030609010102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sven,<br>
<br>
What the other Sven described sounded quite general along the lines of
what you're suggesting.&nbsp; It would certainly be good in such a framework
to make a validation cycle trivial to enable, i.e., just an extension
with a generic reusable validator trigger.<br>
<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:hkk94l$h59$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Hasan, Sven, Ed,

wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?

Sven

Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Sven,

This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?

Sven Efftinge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hasan Ceylan schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">The aim of EMF Builder is to validate and generate java artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all

and does this with the dependencies considered (validates and
generates the dependent models)

XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
</pre>
</blockquote>
<pre wrap="">No, I didn't meant anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).

I have blogged about the builder infrastructure in general:
<a class="moz-txt-link-freetext" href=" http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html"> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html</a>

The participant hook had been introduced with M5 and is demoed on
the new &amp; noteworthy page.

Cheers,
Sven


</pre>
<blockquote type="cite">
<pre wrap="">Hasan

Sven Efftinge wrote:

</pre>
<blockquote type="cite">
<pre wrap="">With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.

b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.

There's a short video demonstrating the second hook in our n&amp;n
document
see M5/ProjectBuilder
(<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php"> http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php</a>)


Sven

Hasan Ceylan schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Sven,

Would love to test with Xtext + EMF Index bench.

Would you be so kind to give me directions to set up a
development bench?

Regards,
Hasan

Sven Efftinge wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hi Hasan,

how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.

Cheers,
Sven

</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">&lt;SNIP&gt;

</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------080709090205030609010102--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619406 is a reply to message #512721] Sat, 06 February 2010 13:17 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven Efftinge
Messages: 1759
Registered: July 2009
Senior Member
Yes, Xtext's builder infrastructure is not specific to Xtext or ecore,
but allows to "build" any kind of EMF resource in the workspace.
However, we do not reuse the ResourceFactory.Registry.INSTANCE but have
a Registry for so called IResourceServiceProviders.
So if you want to have your EMF models built, just implement and
register one.

Cheers,
Sven

Ed Merks schrieb:
> Sven,
>
> What the other Sven described sounded quite general along the lines of
> what you're suggesting. It would certainly be good in such a framework
> to make a validation cycle trivial to enable, i.e., just an extension
> with a generic reusable validator trigger.
>
>
> Sven Krause wrote:
>> Hi Hasan, Sven, Ed,
>>
>> wouldn't it make sense to have such an background build/gen job not only
>> limited to ecore/gen/xtext? The most emf based models are registered
>> with its package factory and the potential file extension. So it should
>> be easily possible to identify each kind of model of model files within
>> the marked projects and launch the generic validate/build build hook for
>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>> a special case. PS:the change of a base model might/should trigger the
>> dependent model build cycle too.
>>
>> Sven
>>
>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>
>>> Yes, I think it definitely makes sense at some point.
>>> Maybe we should work on extracting that functionality during the next
>>> release train?
>>>
>>> Sven
>>>
>>> Ed Merks schrieb:
>>>
>>>> Sven,
>>>>
>>>> This sounds cool too, and definitely related. I wonder if something
>>>> of general utility like this makes sense to separate out from Xtext
>>>> itself?
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>
>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>> genodel:
>>>>>> 1) Change the ecore
>>>>>> 2) open genmodel
>>>>>> 3) Issue generate all
>>>>>>
>>>>>> and does this with the dependencies considered (validates and
>>>>>> generates the dependent models)
>>>>>>
>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>
>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>> builder infraststructure in Xtext.
>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>> affected resources, it validates the affected resources and it
>>>>> provides two extension points:
>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>> 2) one to register participants, which can do arbitrary work based
>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>> affected genmodels and epackages).
>>>>>
>>>>> I have blogged about the builder infrastructure in general:
>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>
>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>> the new & noteworthy page.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>> and
>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>> also
>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>
>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>> This one get's a call after each build passed in the
>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>> code generation.
>>>>>>>
>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>> document
>>>>>>> see M5/ProjectBuilder
>>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>>
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> Hello Sven,
>>>>>>>>
>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>
>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>> development bench?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Hasan,
>>>>>>>>>
>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>> <SNIP>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619408 is a reply to message #512710] Sat, 06 February 2010 13:29 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan Ceylan
Messages: 198
Registered: July 2009
Senior Member
Hello Sven,

First you may find the proposal draft here:
http://ebm.batoo.org/index.php/Main_Page

and, yes I definitely target a cycle with the dependencies resolved both in
the workspace and emf registry, and any change / error flag transitively
will affect the downstream models.

Frankly I hadn't though about caching all the extension from the registry. I
should add that as an enhancement request.

Hasan

Sven Krause wrote:

> Hi Hasan, Sven, Ed,
>
> wouldn't it make sense to have such an background build/gen job not only
> limited to ecore/gen/xtext? The most emf based models are registered
> with its package factory and the potential file extension. So it should
> be easily possible to identify each kind of model of model files within
> the marked projects and launch the generic validate/build build hook for
> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
> a special case. PS:the change of a base model might/should trigger the
> dependent model build cycle too.
>
> Sven
>
> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>> Yes, I think it definitely makes sense at some point.
>> Maybe we should work on extracting that functionality during the next
>> release train?
>>
>> Sven
>>
>> Ed Merks schrieb:
>>> Sven,
>>>
>>> This sounds cool too, and definitely related. I wonder if something
>>> of general utility like this makes sense to separate out from Xtext
>>> itself?
>>>
>>> Sven Efftinge wrote:
>>>> Hasan Ceylan schrieb:
>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>> Basically automates what you would do when you have an ecore and a
>>>>> genodel:
>>>>> 1) Change the ecore
>>>>> 2) open genmodel
>>>>> 3) Issue generate all
>>>>>
>>>>> and does this with the dependencies considered (validates and
>>>>> generates the dependent models)
>>>>>
>>>>> XText does this automatically with the mwe runner. Are you
>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>> generation is automated? I just couldn't get it, sorry
>>>>
>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>> builder infraststructure in Xtext.
>>>> It is just exactly what you have in mind. It listenes on resource
>>>> changes (is triggered on save), it computes the transtive hull of
>>>> affected resources, it validates the affected resources and it
>>>> provides two extension points:
>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>> languages) (e.g. *.ecore, *.genmodel)
>>>> 2) one to register participants, which can do arbitrary work based
>>>> on the outcome of a build. (E.g. to start the generation of any
>>>> affected genmodels and epackages).
>>>>
>>>> I have blogged about the builder infrastructure in general:
>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>
>>>> The participant hook had been introduced with M5 and is demoed on
>>>> the new & noteworthy page.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
>>>>
>>>>>
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> With Xtext M5 it is basically a matter of
>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>> and
>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>> also
>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>
>>>>>> b) implementing and registering IBuildParticipant.
>>>>>> This one get's a call after each build passed in the
>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>> code generation.
>>>>>>
>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>> document
>>>>>> see M5/ProjectBuilder
>>>>>>
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>
>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>> development bench?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>> Hi Hasan,
>>>>>>>>
>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sven
>>>>>>>>
>>>>> <SNIP>
>>>>>
>>>>
>>>>
>>
>>

--

Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647


From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."

--
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619409 is a reply to message #619408] Sun, 07 February 2010 04:33 Go to previous messageGo to previous message
Sven Krause is currently offline Sven Krause
Messages: 64
Registered: July 2009
Member
Hi Hasan, Sven

we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?

Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
> Hello Sven,
>
> First you may find the proposal draft here:
> http://ebm.batoo.org/index.php/Main_Page
>
> and, yes I definitely target a cycle with the dependencies resolved both in
> the workspace and emf registry, and any change / error flag transitively
> will affect the downstream models.
>
> Frankly I hadn't though about caching all the extension from the registry. I
> should add that as an enhancement request.
>
> Hasan
>
> Sven Krause wrote:
>
>
>> Hi Hasan, Sven, Ed,
>>
>> wouldn't it make sense to have such an background build/gen job not only
>> limited to ecore/gen/xtext? The most emf based models are registered
>> with its package factory and the potential file extension. So it should
>> be easily possible to identify each kind of model of model files within
>> the marked projects and launch the generic validate/build build hook for
>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>> a special case. PS:the change of a base model might/should trigger the
>> dependent model build cycle too.
>>
>> Sven
>>
>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>
>>> Yes, I think it definitely makes sense at some point.
>>> Maybe we should work on extracting that functionality during the next
>>> release train?
>>>
>>> Sven
>>>
>>> Ed Merks schrieb:
>>>
>>>> Sven,
>>>>
>>>> This sounds cool too, and definitely related. I wonder if something
>>>> of general utility like this makes sense to separate out from Xtext
>>>> itself?
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>
>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>> genodel:
>>>>>> 1) Change the ecore
>>>>>> 2) open genmodel
>>>>>> 3) Issue generate all
>>>>>>
>>>>>> and does this with the dependencies considered (validates and
>>>>>> generates the dependent models)
>>>>>>
>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>
>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>> builder infraststructure in Xtext.
>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>> affected resources, it validates the affected resources and it
>>>>> provides two extension points:
>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>> 2) one to register participants, which can do arbitrary work based
>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>> affected genmodels and epackages).
>>>>>
>>>>> I have blogged about the builder infrastructure in general:
>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>
>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>> the new & noteworthy page.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>> and
>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>> also
>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>
>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>> This one get's a call after each build passed in the
>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>> code generation.
>>>>>>>
>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>> document
>>>>>>> see M5/ProjectBuilder
>>>>>>>
>>>>>>>
> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> Hello Sven,
>>>>>>>>
>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>
>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>> development bench?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Hasan,
>>>>>>>>>
>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>> <SNIP>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Previous Topic:Appeal for review from modeling community to review EMF Build Manager Project Proposal
Next Topic:[Announce] Eclipse/OMG Symposium 2010
Goto Forum:
  


Current Time: Fri Jul 25 14:23:36 EDT 2014

Powered by FUDForum. Page generated in 0.04729 seconds