Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » An appeal for modeling community review to new "EMF Build Manager Project" Proposal
| An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511286] |
Mon, 01 February 2010 05:41  |
 Hasan Ceylan
Messages: 198
Registered: July 2009 |
Senior Member |
|
|
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 #511331 is a reply to message #511286] |
Mon, 01 February 2010 10:07  |
Ed Merks
Messages: 33142
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.
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?<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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511394 is a reply to message #511331] |
Mon, 01 February 2010 09:24 |
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 #512212 is a reply to message #511394] |
Thu, 04 February 2010 12:20 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512462 is a reply to message #512212] |
Fri, 05 February 2010 04:02 |
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 #512478 is a reply to message #512462] |
Fri, 05 February 2010 09:20 |
Sven Efftinge
Messages: 1823
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
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512500 is a reply to message #512499] |
Fri, 05 February 2010 10:09 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512521 is a reply to message #512500] |
Fri, 05 February 2010 06:18 |
Ed Merks
Messages: 33142
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>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512598 is a reply to message #512521] |
Fri, 05 February 2010 10:06 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512719 is a reply to message #512598] |
Sat, 06 February 2010 13:10 |
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 #512720 is a reply to message #512719] |
Sat, 06 February 2010 13:10 |
Ed Merks
Messages: 33142
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. 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 & 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&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=""><SNIP>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------080709090205030609010102--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512724 is a reply to message #512720] |
Sat, 06 February 2010 18:17 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512728 is a reply to message #512719] |
Sat, 06 February 2010 18:29 |
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 #512754 is a reply to message #512728] |
Sun, 07 February 2010 09:33 |
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 #512755 is a reply to message #512724] |
Sun, 07 February 2010 09:35 |
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 #512777 is a reply to message #512754] |
Sun, 07 February 2010 09:50 |
Ed Merks
Messages: 33142
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. 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 & 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&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=""><SNIP>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------050704030205090700090909--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512838 is a reply to message #512777] |
Mon, 08 February 2010 06:56 |
Sven Efftinge
Messages: 1823
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
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512840 is a reply to message #512754] |
Mon, 08 February 2010 06:58 |
Sven Efftinge
Messages: 1823
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
|
|
| | |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512928 is a reply to message #512840] |
Mon, 08 February 2010 11:33 |
Ed Merks
Messages: 33142
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>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512987 is a reply to message #512961] |
Mon, 08 February 2010 09:02 |
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 #513126 is a reply to message #512777] |
Mon, 08 February 2010 23:55 |
Yves YANG
Messages: 688
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. We are investigating to use it in=20
PMF.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </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" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> 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. 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 & 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&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""><SNIP>
=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 #513701 is a reply to message #513298] |
Wed, 10 February 2010 21:31 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Sven, please seem my reply below..
| Sven Efftinge wrote on Tue, 09 February 2010 11:38 | Miles Parker schrieb:
> BTW, can I put in a plea for people to extract everything that isn't
> immediately relevant from there forum replies? i.e. don't just hit
> "quote reply". It makes for a lot of scrolling and hard to follow
> threads in the new web interface.
As I'm using a newsreader, I'ld like to ask for the contrary 
One can tell whether people use a newsreader or the forum just by
looking at how they quote things 
Anyway, I'll check out whether I can use the forum as well, since that
way I'll have means to reference existing threads.
Sven
|
...keep scrolling...
...
(I'm down here) 
Huge digression... Yes, it's an interesting little mis-match in technology / culture. There are great advantages to both. Personally, I like the newsreader, but I switched because as you indicate way up there somewhere, it fits in better with a web-centric approach. Oh and my newsreader Unison stopped working when I upgraded to Snow Leopard and they don't seem to be updating the product anymore. grr.. But it's amazing to me that someone hasn't figured out a better way to do treaded discussions by now. I tried Google Wave but I think it's more complicated then is needed. I saw a demo of something of a Notes reader on planet Eclipse a while back that looked really interesting. I'm really grateful that Denis et. al. got a web forum up as its essential to communicate with the broad set of users who just aren't going to have newsreaders, but PHP forums do leave a little to be desired. At some point in the future it would be really cool to have something that had a nice front end and a well-integrated Rich Client plugin for Eclipse. Perhaps with E4 wuch a thing wouldn't be too hard if there were an existing back end somewhere.
|
|
| | |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622063 is a reply to message #511286] |
Mon, 01 February 2010 10:07 |
Ed Merks
Messages: 33142
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.
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?<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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622064 is a reply to message #511331] |
Mon, 01 February 2010 14:10 |
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 #622069 is a reply to message #622064] |
Thu, 04 February 2010 12:20 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622075 is a reply to message #512212] |
Fri, 05 February 2010 08:53 |
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 #622076 is a reply to message #622075] |
Fri, 05 February 2010 09:20 |
Sven Efftinge
Messages: 1823
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
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622078 is a reply to message #512499] |
Fri, 05 February 2010 10:09 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622080 is a reply to message #512500] |
Fri, 05 February 2010 11:16 |
Ed Merks
Messages: 33142
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>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622081 is a reply to message #622080] |
Fri, 05 February 2010 15:01 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622083 is a reply to message #622081] |
Sat, 06 February 2010 17:33 |
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 #622084 is a reply to message #622083] |
Sat, 06 February 2010 17:56 |
Ed Merks
Messages: 33142
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. 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 & 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&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=""><SNIP>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------080709090205030609010102--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622085 is a reply to message #622084] |
Sat, 06 February 2010 18:17 |
Sven Efftinge
Messages: 1823
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
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622086 is a reply to message #622083] |
Sat, 06 February 2010 18:29 |
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 #622087 is a reply to message #512728] |
Sun, 07 February 2010 09:33 |
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 #622088 is a reply to message #512724] |
Sun, 07 February 2010 09:35 |
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 #622089 is a reply to message #512754] |
Sun, 07 February 2010 14:38 |
Ed Merks
Messages: 33142
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. 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 & 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&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=""><SNIP>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------050704030205090700090909--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622090 is a reply to message #622089] |
Mon, 08 February 2010 06:56 |
Sven Efftinge
Messages: 1823
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
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622092 is a reply to message #512754] |
Mon, 08 February 2010 06:58 |
Sven Efftinge
Messages: 1823
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
|
|
| | |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622095 is a reply to message #512840] |
Mon, 08 February 2010 11:33 |
Ed Merks
Messages: 33142
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>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #622098 is a reply to message #512961] |
Mon, 08 February 2010 13:51 |
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 #622102 is a reply to message #622089] |
Mon, 08 February 2010 23:55 |
Yves YANG
Messages: 688
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. We are investigating to use it in=20
PMF.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </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" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> 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. 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 & 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&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""><SNIP>
=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 #622117 is a reply to message #513298] |
Wed, 10 February 2010 21:31 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Sven, please seem my reply below..
Sven Efftinge wrote on Tue, 09 February 2010 11:38
> Miles Parker schrieb:
> > BTW, can I put in a plea for people to extract everything that isn't
> > immediately relevant from there forum replies? i.e. don't just hit
> > "quote reply". It makes for a lot of scrolling and hard to follow
> > threads in the new web interface.
>
> As I'm using a newsreader, I'ld like to ask for the contrary ;)
> One can tell whether people use a newsreader or the forum just by
> looking at how they quote things :)
>
> Anyway, I'll check out whether I can use the forum as well, since that
> way I'll have means to reference existing threads.
>
> Sven
...keep scrolling...
...
(I'm down here) :d
Huge digression... Yes, it's an interesting little mis-match in technology / culture. There are great advantages to both. Personally, I like the newsreader, but I switched because as you indicate way up there somewhere, it fits in better with a web-centric approach. Oh and my newsreader Unison stopped working when I upgraded to Snow Leopard and they don't seem to be updating the product anymore. grr.. But it's amazing to me that someone hasn't figured out a better way to do treaded discussions by now. I tried Google Wave but I think it's more complicated then is needed. I saw a demo of something of a Notes reader on planet Eclipse a while back that looked really interesting. I'm really grateful that Denis et. al. got a web forum up as its essential to communicate with the broad set of users who just aren't going to have newsreaders, but PHP forums do leave a little to be desired. At some point in the future ;) it would be really cool to have something that had a nice front end and a well-integrated Rich Client plugin for Eclipse. Perhaps with E4 wuch a thing wouldn't be too hard if there were an existing back end somewhere.
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 19:57:40 GMT 2024
Powered by FUDForum. Page generated in 0.09730 seconds |
] 
Search
Help
Register
Login
Home
