Home » Modeling » Modeling (top-level project) » Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511333] |
Mon, 01 February 2010 05:07  |
Eclipse User |
|
|
|
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--
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #511391 is a reply to message #511333] |
Mon, 01 February 2010 09:10  |
| Eclipse User |
|
|
|
Hello Ed,
Thanks for sharing you comments. I will surely take a look at referenced
wizard / builder.
I think the project will handle situations like this well enough since:
1) It has built-in support for dependency chain, meaning only the affected
models in the change chain is marked for validation & generation
2) It is not a must, to have the nature to have an EMF project, since you
can add / remove the nature by project->right click
3) Builder triggers on save rather then "working-copy".
4) This can further be improved by adding a grace-period and / or max-depth
configuration. Meaning, consecutive changes to models within a time window
will gather changes and start the *real* build only after the grace period
expires. Reaching of *Max-depth* can place a mark on the status bar as well
as putting validation markers on the affected-but-yet-processed resources.
Clicking on the status bar notification or quick fix on the markers, can
trigger partition or deal with the rest of the process.
5) An unavoidable requirement of working with (even for XX number of
projects in a single workspace)is, whatever the chosen way of dealing with
EMF validation and build, eventually you have to generate. When this happens
EBM's promise is to relieve the workspace to the extent possible, with smart
dependency tracking and putting resource-locks on only the provisional
extension of the build process of the dirty models. This means, putting lock
only on the list of models in the dirty models and java package namespace of
the gemodels.
6) One of the nice features of the workspace resource locks is, say you are
working on a chanin of models. After some editing, you save your work, which
is where the builder kicks in. It certainly works in the background and as
long as you do not save an editor in the affected resources (chain of
dependency and genmodel java artifacts), further save blocks the UI if the
build is still going on. Here the user has option which includes
i) revertion the save request, which will go back to the editing domain
ii) Can halt the builder and postpone the build process altogether to a
futher time
7) Since the validation and generation do not modify the model resources
this has minimal impact on post-build dirt-editor merge.
One of the interesting outcome of my test with a sample workspace with 5
interdependent ecore + genmodel is while normally it takes about few
secconds to generate a genmodel, the whole process takes 2 times of that
time. I guess, this is due to, CPU caching and less processing and stack
operation due to less resortion to UI both in terms of painting and going
all the way down to OS UI bindings.
I am well aware of the cost of nature/builder integration for a relatively
large EMF workspace. But this is / can become a -no-longer-a-thread by
i) Smart handling of the models (Hey after all we arfe dealing with the
models right, which is exactly for this very reason)
2) Computers and processors evolved drastically since the introduction of
EMF. (that is about 8-10x) [1] [2]
Regards,
Hasan
[1] http://www.cpubenchmark.net/high_end_cpus.html
[2] http://www.cpubenchmark.net/low_end_cpus.html
Ed Merks wrote:
> Hasan,
>
> This posting only has your CV, but I found it in one of your other cross
> posts.
>
> I think that the extremely well hidden generator wizard addresses many
> of these concerns though there's certainly room for improvements:
>
> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
generate-my-28.html
>
> An issue I see with defining a builder is that it involves defining a
> project nature which is something we've avoided in the core so far.
> Automatically performing actions that can be fairly expensive, such as
> validating all the Ecore models in the workspace, or generating all the
> GenModels in the workspace, is also something I'd be reluctant about.
> I suppose if it's done in the background, it's not such a concern. I
> wonder how much of the benefit could achieved by enhancing the
> GenerateHandler, e.g., to make it launch a job instead of blocking the
> IDE?
>
>
> Hasan Ceylan wrote:
>> The PDF has been attached...
>>
>>
>>> Hello,
>>>
>>> Attached is the PDF version of the forementioned EMF Build Manager
>>> Project Proposal.
>>>
>>> I kindly ask EMF community members and EMF (and subprojects) committers
>>> to review the document and forward their thoughts.
>>>
>>> I am also looking for mentors for the proposal.
>>>
>>> Below is the extraction of "Background" of the project. Please remember
>>> to review the attached PDF for full proposal draft.
>>>
>>> I apoligize for crossposting...
>>>
>>> ============================================================ =
>>> BACKGROUND
>>>
>>> EMF has been around for a long time. But the fact is that it lacked the
>>> necessary IDE Build Manager integration ever since.
>>> We think, the current code generation and validation toolset is below
>>> eclipse UI quality standards and fell behind similar facility provisions
>>> from the other projects.
>>>
>>> For instance, given the current infrastructure, if a developer is
>>> working with two ecore models that are dependent each other along with
>>> their respective genmodel, when developer makes a change in the base
>>> model that requires a change in the dependent ecore model, will need
>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>> executions along with several clicks to locate the action and run them.
>>>
>>> Also during the generation process, the UI is blocked and having
>>> finished the change on the base ecore, the developer cannot continue
>>> working on the second ecore before the base model generation finishes.
>>> Further more there is also need to switch to genmodels twice and
>>> initiate generation delibarately.
>>>
>>> In addition to this, if developer would like to validate the model in
>>> between the unit of the works, that will require clicks to locate the
>>> validation action, click to run the action and click to dismiss the
>>> feedback.
>>>
>>> It is also in our experience that the genmodel editors are kept open
>>> just for triggering code genration. Furthermore, this not only clutters
>>> the editor folder with unneeded editors, but also breaks the 'editor'
>>> description for genmodel, as usualy once genmodels are set up, they very
>>> seldom change, but needed to be open for code generation.
>>> When used on large workspaces with more than a few model, problem
>>> becomes a real burden.
>>>
>>> This is where EBM steps in and delegates much of the work to background
>>> build manager and prevents user distrubition with using the instruments
>>> like
>>> auto build on resource save, Marker and Problem View instrumentation to
>>> provide feedback.
>>> ============================================================ =
>>>
>>> Regards,
>>>
>>>
>>
>>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512211 is a reply to message #511391] |
Thu, 04 February 2010 07:20 |
| Eclipse User |
|
|
|
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 #512459 is a reply to message #512211] |
Fri, 05 February 2010 03:53 |
| Eclipse User |
|
|
|
Hello Sven,
Would love to test with Xtext + EMF Index bench.
Would you be so kind to give me directions to set up a development bench?
Regards,
Hasan
Sven Efftinge wrote:
> Hi Hasan,
>
> how is this idea related to Xtext's builder infrastructure and EMF
> index? It seems to be a perfect match for what you want to achieve.
>
> Cheers,
> Sven
>
> Hasan Ceylan schrieb:
>> Hello Ed,
>>
>> Thanks for sharing you comments. I will surely take a look at referenced
>> wizard / builder.
>>
>> I think the project will handle situations like this well enough since:
>> 1) It has built-in support for dependency chain, meaning only the
>> affected models in the change chain is marked for validation & generation
>> 2) It is not a must, to have the nature to have an EMF project, since you
>> can add / remove the nature by project->right click
>> 3) Builder triggers on save rather then "working-copy".
>> 4) This can further be improved by adding a grace-period and / or
>> max-depth configuration. Meaning, consecutive changes to models within a
>> time window will gather changes and start the *real* build only after the
>> grace period expires. Reaching of *Max-depth* can place a mark on the
>> status bar as well as putting validation markers on the
>> affected-but-yet-processed resources. Clicking on the status bar
>> notification or quick fix on the markers, can trigger partition or deal
>> with the rest of the process. 5) An unavoidable requirement of working
>> with (even for XX number of projects in a single workspace)is, whatever
>> the chosen way of dealing with EMF validation and build, eventually you
>> have to generate. When this happens EBM's promise is to relieve the
>> workspace to the extent possible, with smart dependency tracking and
>> putting resource-locks on only the provisional extension of the build
>> process of the dirty models. This means, putting lock only on the list of
>> models in the dirty models and java package namespace of the gemodels.
>> 6) One of the nice features of the workspace resource locks is, say you
>> are working on a chanin of models. After some editing, you save your
>> work, which is where the builder kicks in. It certainly works in the
>> background and as long as you do not save an editor in the affected
>> resources (chain of dependency and genmodel java artifacts), further save
>> blocks the UI if the build is still going on. Here the user has option
>> which includes i) revertion the save request, which will go back to the
>> editing domain ii) Can halt the builder and postpone the build process
>> altogether to a futher time
>> 7) Since the validation and generation do not modify the model resources
>> this has minimal impact on post-build dirt-editor merge.
>>
>>
>> One of the interesting outcome of my test with a sample workspace with 5
>> interdependent ecore + genmodel is while normally it takes about few
>> secconds to generate a genmodel, the whole process takes 2 times of that
>> time. I guess, this is due to, CPU caching and less processing and stack
>> operation due to less resortion to UI both in terms of painting and going
>> all the way down to OS UI bindings.
>>
>> I am well aware of the cost of nature/builder integration for a
>> relatively large EMF workspace. But this is / can become a
>> -no-longer-a-thread by i) Smart handling of the models (Hey after all we
>> arfe dealing with the models right, which is exactly for this very
>> reason) 2) Computers and processors evolved drastically since the
>> introduction of EMF. (that is about 8-10x) [1] [2]
>>
>> Regards,
>> Hasan
>>
>> [1] http://www.cpubenchmark.net/high_end_cpus.html
>> [2] http://www.cpubenchmark.net/low_end_cpus.html
>>
>>
>> Ed Merks wrote:
>>
>>> Hasan,
>>>
>>> This posting only has your CV, but I found it in one of your other cross
>>> posts.
>>>
>>> I think that the extremely well hidden generator wizard addresses many
>>> of these concerns though there's certainly room for improvements:
>>>
>>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
>> generate-my-28.html
>>> An issue I see with defining a builder is that it involves defining a
>>> project nature which is something we've avoided in the core so far.
>>> Automatically performing actions that can be fairly expensive, such as
>>> validating all the Ecore models in the workspace, or generating all the
>>> GenModels in the workspace, is also something I'd be reluctant about.
>>> I suppose if it's done in the background, it's not such a concern. I
>>> wonder how much of the benefit could achieved by enhancing the
>>> GenerateHandler, e.g., to make it launch a job instead of blocking the
>>> IDE?
>>>
>>>
>>> Hasan Ceylan wrote:
>>>> The PDF has been attached...
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> Attached is the PDF version of the forementioned EMF Build Manager
>>>>> Project Proposal.
>>>>>
>>>>> I kindly ask EMF community members and EMF (and subprojects)
>>>>> committers to review the document and forward their thoughts.
>>>>>
>>>>> I am also looking for mentors for the proposal.
>>>>>
>>>>> Below is the extraction of "Background" of the project. Please
>>>>> remember to review the attached PDF for full proposal draft.
>>>>>
>>>>> I apoligize for crossposting...
>>>>>
>>>>> ============================================================ =
>>>>> BACKGROUND
>>>>>
>>>>> EMF has been around for a long time. But the fact is that it lacked
>>>>> the necessary IDE Build Manager integration ever since.
>>>>> We think, the current code generation and validation toolset is below
>>>>> eclipse UI quality standards and fell behind similar facility
>>>>> provisions from the other projects.
>>>>>
>>>>> For instance, given the current infrastructure, if a developer is
>>>>> working with two ecore models that are dependent each other along with
>>>>> their respective genmodel, when developer makes a change in the base
>>>>> model that requires a change in the dependent ecore model, will need
>>>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>>>> executions along with several clicks to locate the action and run
>>>>> them.
>>>>>
>>>>> Also during the generation process, the UI is blocked and having
>>>>> finished the change on the base ecore, the developer cannot continue
>>>>> working on the second ecore before the base model generation finishes.
>>>>> Further more there is also need to switch to genmodels twice and
>>>>> initiate generation delibarately.
>>>>>
>>>>> In addition to this, if developer would like to validate the model in
>>>>> between the unit of the works, that will require clicks to locate the
>>>>> validation action, click to run the action and click to dismiss the
>>>>> feedback.
>>>>>
>>>>> It is also in our experience that the genmodel editors are kept open
>>>>> just for triggering code genration. Furthermore, this not only
>>>>> clutters the editor folder with unneeded editors, but also breaks the
>>>>> 'editor' description for genmodel, as usualy once genmodels are set
>>>>> up, they very seldom change, but needed to be open for code
>>>>> generation. When used on large workspaces with more than a few model,
>>>>> problem becomes a real burden.
>>>>>
>>>>> This is where EBM steps in and delegates much of the work to
>>>>> background build manager and prevents user distrubition with using the
>>>>> instruments like
>>>>> auto build on resource save, Marker and Problem View instrumentation
>>>>> to provide feedback.
>>>>> ============================================================ =
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>
>>
>
>
--
Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647
From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."
--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512479 is a reply to message #512459] |
Fri, 05 February 2010 04:20 |
| Eclipse User |
|
|
|
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 #512498 is a reply to message #512491] |
Fri, 05 February 2010 00:14 |
| Eclipse User |
|
|
|
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 #512523 is a reply to message #512498] |
Fri, 05 February 2010 01:24 |
| Eclipse User |
|
|
|
Sven,
This sounds cool too, and definitely related. I wonder if something of
general utility like this makes sense to separate out from Xtext itself?
Sven Efftinge wrote:
> Hasan Ceylan schrieb:
>> The aim of EMF Builder is to validate and generate java artifacts on
>> ecore, xmi and genmodel based on changes on the resources. Basically
>> automates what you would do when you have an ecore and a genodel:
>> 1) Change the ecore
>> 2) open genmodel
>> 3) Issue generate all
>>
>> and does this with the dependencies considered (validates and
>> generates the dependent models)
>>
>> XText does this automatically with the mwe runner. Are you suggesting
>> integrating the xtext mwe into EMFBuilder so that the generation is
>> automated? I just couldn't get it, sorry
>
> No, I didn't meant anything MWE related. I was talking of the new
> builder infraststructure in Xtext.
> It is just exactly what you have in mind. It listenes on resource
> changes (is triggered on save), it computes the transtive hull of
> affected resources, it validates the affected resources and it
> provides two extension points:
> 1) one to register EMF-based languages (they don't have to be Xtext
> languages) (e.g. *.ecore, *.genmodel)
> 2) one to register participants, which can do arbitrary work based on
> the outcome of a build. (E.g. to start the generation of any affected
> genmodels and epackages).
>
> I have blogged about the builder infrastructure in general:
> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>
> The participant hook had been introduced with M5 and is demoed on the
> new & noteworthy page.
>
> Cheers,
> Sven
>
>
>>
>> Hasan
>>
>> Sven Efftinge wrote:
>>
>>> With Xtext M5 it is basically a matter of
>>> a) implementing and registering IResourceServiceProvider for ecore and
>>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>>> provides the needed hook to compute the transitive hull of changes.
>>>
>>> b) implementing and registering IBuildParticipant.
>>> This one get's a call after each build passed in the
>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>> code generation.
>>>
>>> There's a short video demonstrating the second hook in our n&n document
>>> see M5/ProjectBuilder
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>> Sven
>>>
>>> Hasan Ceylan schrieb:
>>>> Hello Sven,
>>>>
>>>> Would love to test with Xtext + EMF Index bench.
>>>>
>>>> Would you be so kind to give me directions to set up a development
>>>> bench?
>>>>
>>>> Regards,
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hi Hasan,
>>>>>
>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>> <SNIP>
>>
>
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512597 is a reply to message #512523] |
Fri, 05 February 2010 10:01 |
| Eclipse User |
|
|
|
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 #512710 is a reply to message #512597] |
Sat, 06 February 2010 12:33 |
| Eclipse User |
|
|
|
Hi Hasan, Sven, Ed,
wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.
Sven
Am 05.02.2010 16:01, schrieb Sven Efftinge:
> Yes, I think it definitely makes sense at some point.
> Maybe we should work on extracting that functionality during the next
> release train?
>
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> This sounds cool too, and definitely related. I wonder if something
>> of general utility like this makes sense to separate out from Xtext
>> itself?
>>
>> Sven Efftinge wrote:
>>> Hasan Ceylan schrieb:
>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>> Basically automates what you would do when you have an ecore and a
>>>> genodel:
>>>> 1) Change the ecore
>>>> 2) open genmodel
>>>> 3) Issue generate all
>>>>
>>>> and does this with the dependencies considered (validates and
>>>> generates the dependent models)
>>>>
>>>> XText does this automatically with the mwe runner. Are you
>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>> generation is automated? I just couldn't get it, sorry
>>>
>>> No, I didn't meant anything MWE related. I was talking of the new
>>> builder infraststructure in Xtext.
>>> It is just exactly what you have in mind. It listenes on resource
>>> changes (is triggered on save), it computes the transtive hull of
>>> affected resources, it validates the affected resources and it
>>> provides two extension points:
>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>> languages) (e.g. *.ecore, *.genmodel)
>>> 2) one to register participants, which can do arbitrary work based
>>> on the outcome of a build. (E.g. to start the generation of any
>>> affected genmodels and epackages).
>>>
>>> I have blogged about the builder infrastructure in general:
>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>
>>> The participant hook had been introduced with M5 and is demoed on
>>> the new & noteworthy page.
>>>
>>> Cheers,
>>> Sven
>>>
>>>
>>>>
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> With Xtext M5 it is basically a matter of
>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>> and
>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>> also
>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>
>>>>> b) implementing and registering IBuildParticipant.
>>>>> This one get's a call after each build passed in the
>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>> code generation.
>>>>>
>>>>> There's a short video demonstrating the second hook in our n&n
>>>>> document
>>>>> see M5/ProjectBuilder
>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>
>>>>>
>>>>> Sven
>>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>> Hello Sven,
>>>>>>
>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>
>>>>>> Would you be so kind to give me directions to set up a
>>>>>> development bench?
>>>>>>
>>>>>> Regards,
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hi Hasan,
>>>>>>>
>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>> <SNIP>
>>>>
>>>
>>>
>
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512721 is a reply to message #512710] |
Sat, 06 February 2010 12:56 |
| Eclipse User |
|
|
|
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--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512722 is a reply to message #512721] |
Sat, 06 February 2010 13:17 |
| Eclipse User |
|
|
|
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 #512729 is a reply to message #512710] |
Sat, 06 February 2010 08:44 |
| Eclipse User |
|
|
|
Hello Sven,
First you may find the proposal draft here:
http://ebm.batoo.org/index.php/Main_Page
and, yes I definitely target a cycle with the dependencies resolved both in
the workspace and emf registry, and any change / error flag transitively
will affect the downstream models.
Frankly I hadn't though about caching all the extension from the registry. I
should add that as an enhancement request.
Hasan
Sven Krause wrote:
> Hi Hasan, Sven, Ed,
>
> wouldn't it make sense to have such an background build/gen job not only
> limited to ecore/gen/xtext? The most emf based models are registered
> with its package factory and the potential file extension. So it should
> be easily possible to identify each kind of model of model files within
> the marked projects and launch the generic validate/build build hook for
> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
> a special case. PS:the change of a base model might/should trigger the
> dependent model build cycle too.
>
> Sven
>
> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>> Yes, I think it definitely makes sense at some point.
>> Maybe we should work on extracting that functionality during the next
>> release train?
>>
>> Sven
>>
>> Ed Merks schrieb:
>>> Sven,
>>>
>>> This sounds cool too, and definitely related. I wonder if something
>>> of general utility like this makes sense to separate out from Xtext
>>> itself?
>>>
>>> Sven Efftinge wrote:
>>>> Hasan Ceylan schrieb:
>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>> Basically automates what you would do when you have an ecore and a
>>>>> genodel:
>>>>> 1) Change the ecore
>>>>> 2) open genmodel
>>>>> 3) Issue generate all
>>>>>
>>>>> and does this with the dependencies considered (validates and
>>>>> generates the dependent models)
>>>>>
>>>>> XText does this automatically with the mwe runner. Are you
>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>> generation is automated? I just couldn't get it, sorry
>>>>
>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>> builder infraststructure in Xtext.
>>>> It is just exactly what you have in mind. It listenes on resource
>>>> changes (is triggered on save), it computes the transtive hull of
>>>> affected resources, it validates the affected resources and it
>>>> provides two extension points:
>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>> languages) (e.g. *.ecore, *.genmodel)
>>>> 2) one to register participants, which can do arbitrary work based
>>>> on the outcome of a build. (E.g. to start the generation of any
>>>> affected genmodels and epackages).
>>>>
>>>> I have blogged about the builder infrastructure in general:
>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>
>>>> The participant hook had been introduced with M5 and is demoed on
>>>> the new & noteworthy page.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
>>>>
>>>>>
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> With Xtext M5 it is basically a matter of
>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>> and
>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>> also
>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>
>>>>>> b) implementing and registering IBuildParticipant.
>>>>>> This one get's a call after each build passed in the
>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>> code generation.
>>>>>>
>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>> document
>>>>>> see M5/ProjectBuilder
>>>>>>
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>
>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>> development bench?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>> Hi Hasan,
>>>>>>>>
>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sven
>>>>>>>>
>>>>> <SNIP>
>>>>>
>>>>
>>>>
>>
>>
--
Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647
From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."
--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512756 is a reply to message #512729] |
Sat, 06 February 2010 23:44 |
| Eclipse User |
|
|
|
Hi Hasan, Sven
we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?
Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
> Hello Sven,
>
> First you may find the proposal draft here:
> http://ebm.batoo.org/index.php/Main_Page
>
> and, yes I definitely target a cycle with the dependencies resolved both in
> the workspace and emf registry, and any change / error flag transitively
> will affect the downstream models.
>
> Frankly I hadn't though about caching all the extension from the registry. I
> should add that as an enhancement request.
>
> Hasan
>
> Sven Krause wrote:
>
>
>> Hi Hasan, Sven, Ed,
>>
>> wouldn't it make sense to have such an background build/gen job not only
>> limited to ecore/gen/xtext? The most emf based models are registered
>> with its package factory and the potential file extension. So it should
>> be easily possible to identify each kind of model of model files within
>> the marked projects and launch the generic validate/build build hook for
>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>> a special case. PS:the change of a base model might/should trigger the
>> dependent model build cycle too.
>>
>> Sven
>>
>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>
>>> Yes, I think it definitely makes sense at some point.
>>> Maybe we should work on extracting that functionality during the next
>>> release train?
>>>
>>> Sven
>>>
>>> Ed Merks schrieb:
>>>
>>>> Sven,
>>>>
>>>> This sounds cool too, and definitely related. I wonder if something
>>>> of general utility like this makes sense to separate out from Xtext
>>>> itself?
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>
>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>> genodel:
>>>>>> 1) Change the ecore
>>>>>> 2) open genmodel
>>>>>> 3) Issue generate all
>>>>>>
>>>>>> and does this with the dependencies considered (validates and
>>>>>> generates the dependent models)
>>>>>>
>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>
>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>> builder infraststructure in Xtext.
>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>> affected resources, it validates the affected resources and it
>>>>> provides two extension points:
>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>> 2) one to register participants, which can do arbitrary work based
>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>> affected genmodels and epackages).
>>>>>
>>>>> I have blogged about the builder infrastructure in general:
>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>
>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>> the new & noteworthy page.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>> and
>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>> also
>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>
>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>> This one get's a call after each build passed in the
>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>> code generation.
>>>>>>>
>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>> document
>>>>>>> see M5/ProjectBuilder
>>>>>>>
>>>>>>>
> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> Hello Sven,
>>>>>>>>
>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>
>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>> development bench?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Hasan,
>>>>>>>>>
>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>> <SNIP>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512757 is a reply to message #512722] |
Sat, 06 February 2010 23:44 |
| Eclipse User |
|
|
|
Hi Sven,
doesn't put this construct extra effort in allowing trigger builds on
any model or did use this explicit as filter?
Sven
Am 06.02.2010 19:17, schrieb Sven Efftinge:
> Yes, Xtext's builder infrastructure is not specific to Xtext or ecore,
> but allows to "build" any kind of EMF resource in the workspace.
> However, we do not reuse the ResourceFactory.Registry.INSTANCE but
> have a Registry for so called IResourceServiceProviders.
> So if you want to have your EMF models built, just implement and
> register one.
>
> Cheers,
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> What the other Sven described sounded quite general along the lines
>> of what you're suggesting. It would certainly be good in such a
>> framework to make a validation cycle trivial to enable, i.e., just an
>> extension with a generic reusable validator trigger.
>>
>>
>> Sven Krause wrote:
>>> Hi Hasan, Sven, Ed,
>>>
>>> wouldn't it make sense to have such an background build/gen job not
>>> only
>>> limited to ecore/gen/xtext? The most emf based models are registered
>>> with its package factory and the potential file extension. So it should
>>> be easily possible to identify each kind of model of model files within
>>> the marked projects and launch the generic validate/build build hook
>>> for
>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>> a special case. PS:the change of a base model might/should trigger the
>>> dependent model build cycle too.
>>>
>>> Sven
>>>
>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>
>>>> Yes, I think it definitely makes sense at some point.
>>>> Maybe we should work on extracting that functionality during the next
>>>> release train?
>>>>
>>>> Sven
>>>>
>>>> Ed Merks schrieb:
>>>>
>>>>> Sven,
>>>>>
>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>> of general utility like this makes sense to separate out from Xtext
>>>>> itself?
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>> genodel:
>>>>>>> 1) Change the ecore
>>>>>>> 2) open genmodel
>>>>>>> 3) Issue generate all
>>>>>>>
>>>>>>> and does this with the dependencies considered (validates and
>>>>>>> generates the dependent models)
>>>>>>>
>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>
>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>> builder infraststructure in Xtext.
>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>> affected resources, it validates the affected resources and it
>>>>>> provides two extension points:
>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>> affected genmodels and epackages).
>>>>>>
>>>>>> I have blogged about the builder infrastructure in general:
>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>
>>>>>>
>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>> the new & noteworthy page.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>> and
>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>> also
>>>>>>>> provides the needed hook to compute the transitive hull of
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>> This one get's a call after each build passed in the
>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to
>>>>>>>> trigger
>>>>>>>> code generation.
>>>>>>>>
>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>> document
>>>>>>>> see M5/ProjectBuilder
>>>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>
>>>>>>>>> Hello Sven,
>>>>>>>>>
>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>
>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>> development bench?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hasan
>>>>>>>>>
>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Hasan,
>>>>>>>>>>
>>>>>>>>>> how is this idea related to Xtext's builder infrastructure
>>>>>>>>>> and EMF
>>>>>>>>>> index? It seems to be a perfect match for what you want to
>>>>>>>>>> achieve.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512774 is a reply to message #512756] |
Sun, 07 February 2010 04:42 |
| Eclipse User |
|
|
|
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--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512844 is a reply to message #512774] |
Sun, 07 February 2010 21:46 |
| Eclipse User |
|
|
|
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 #512846 is a reply to message #512756] |
Sun, 07 February 2010 21:46 |
| Eclipse User |
|
|
|
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 #512929 is a reply to message #512846] |
Mon, 08 February 2010 06:33 |
| Eclipse User |
|
|
|
Sven,
Yes, I'd prefer to see the "generic" indexing be part of the index
project. Do you think support for triggered activities such as builds
or validation should be part of the index project as well?
Sven Efftinge wrote:
> See my other reply in this thread.
> I think such a functionality belongs to the EMF Index project.
>
> Sven
>
> Sven Krause schrieb:
>> Hi Hasan, Sven
>>
>> we have similar capabilities in the flowr project that became base of
>> the new mtf eclipse project. Are you interested to join the project and
>> bring your features into mtf? Or do you prefer to keep it standalone
>> (@Ed, Sven)?
>>
>> Sven
>> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>>> Hello Sven,
>>>
>>> First you may find the proposal draft here:
>>> http://ebm.batoo.org/index.php/Main_Page
>>>
>>> and, yes I definitely target a cycle with the dependencies resolved
>>> both in the workspace and emf registry, and any change / error flag
>>> transitively will affect the downstream models.
>>>
>>> Frankly I hadn't though about caching all the extension from the
>>> registry. I should add that as an enhancement request.
>>>
>>> Hasan
>>>
>>> Sven Krause wrote:
>>>
>>>
>>>> Hi Hasan, Sven, Ed,
>>>>
>>>> wouldn't it make sense to have such an background build/gen job not
>>>> only
>>>> limited to ecore/gen/xtext? The most emf based models are registered
>>>> with its package factory and the potential file extension. So it
>>>> should
>>>> be easily possible to identify each kind of model of model files
>>>> within
>>>> the marked projects and launch the generic validate/build build
>>>> hook for
>>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is
>>>> just
>>>> a special case. PS:the change of a base model might/should trigger the
>>>> dependent model build cycle too.
>>>>
>>>> Sven
>>>>
>>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>>
>>>>> Yes, I think it definitely makes sense at some point.
>>>>> Maybe we should work on extracting that functionality during the next
>>>>> release train?
>>>>>
>>>>> Sven
>>>>>
>>>>> Ed Merks schrieb:
>>>>>
>>>>>> Sven,
>>>>>>
>>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>>> of general utility like this makes sense to separate out from Xtext
>>>>>> itself?
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>>> genodel:
>>>>>>>> 1) Change the ecore
>>>>>>>> 2) open genmodel
>>>>>>>> 3) Issue generate all
>>>>>>>>
>>>>>>>> and does this with the dependencies considered (validates and
>>>>>>>> generates the dependent models)
>>>>>>>>
>>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>>
>>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>>> builder infraststructure in Xtext.
>>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>>> affected resources, it validates the affected resources and it
>>>>>>> provides two extension points:
>>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>>> affected genmodels and epackages).
>>>>>>>
>>>>>>> I have blogged about the builder infrastructure in general:
>>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>>
>>>>>>>
>>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>>> the new & noteworthy page.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>>> a) implementing and registering IResourceServiceProvider for
>>>>>>>>> ecore
>>>>>>>>> and
>>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>>> also
>>>>>>>>> provides the needed hook to compute the transitive hull of
>>>>>>>>> changes.
>>>>>>>>>
>>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>>> This one get's a call after each build passed in the
>>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to
>>>>>>>>> trigger
>>>>>>>>> code generation.
>>>>>>>>>
>>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>>> document
>>>>>>>>> see M5/ProjectBuilder
>>>>>>>>>
>>>>>>>>>
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>>
>>>>>>>>>> Hello Sven,
>>>>>>>>>>
>>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>>
>>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>>> development bench?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hasan
>>>>>>>>>>
>>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Hasan,
>>>>>>>>>>>
>>>>>>>>>>> how is this idea related to Xtext's builder infrastructure
>>>>>>>>>>> and EMF
>>>>>>>>>>> index? It seems to be a perfect match for what you want to
>>>>>>>>>>> achieve.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Sven
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
>
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #512980 is a reply to message #512966] |
Mon, 08 February 2010 08:51 |
| Eclipse User |
|
|
|
Sven & Ed,
I have posted the beta release of EBM. I would appricate you comments and
reviews.
Having not aware of the EMF Index project, I developed an internal builder
state and dependency model (SDK has the code). We should revise that part if
necessary, by the way what is the state of EMF Index project?
Hasan
Sven Efftinge wrote:
> Ed Merks schrieb:
>> Sven,
>>
>> Yes, I'd prefer to see the "generic" indexing be part of the index
>> project. Do you think support for triggered activities such as builds
>> or validation should be part of the index project as well?
>
> Yes, I think so, because it is technically hard to separate between
> these things. A central mechanism which keeps the workspace in sync with
> the index, has everything we need to do validation and further post
> processing (like triggering code generation).
>
> The EMF index should of course *not* provide language specific
> implementations. For instance a GenModel execution for changes in ecore
> or genmodels, like Hassan proposed, clearly belongs elsewhere (e.g.
> EcoreTools).
>
> So far, all that stuff is located in Xtext's repository.
>
> Sven
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #513128 is a reply to message #512774] |
Mon, 08 February 2010 14:14 |
| Eclipse User |
|
|
|
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 #618585 is a reply to message #511333] |
Mon, 01 February 2010 09:10 |
| Eclipse User |
|
|
|
Hello Ed,
Thanks for sharing you comments. I will surely take a look at referenced
wizard / builder.
I think the project will handle situations like this well enough since:
1) It has built-in support for dependency chain, meaning only the affected
models in the change chain is marked for validation & generation
2) It is not a must, to have the nature to have an EMF project, since you
can add / remove the nature by project->right click
3) Builder triggers on save rather then "working-copy".
4) This can further be improved by adding a grace-period and / or max-depth
configuration. Meaning, consecutive changes to models within a time window
will gather changes and start the *real* build only after the grace period
expires. Reaching of *Max-depth* can place a mark on the status bar as well
as putting validation markers on the affected-but-yet-processed resources.
Clicking on the status bar notification or quick fix on the markers, can
trigger partition or deal with the rest of the process.
5) An unavoidable requirement of working with (even for XX number of
projects in a single workspace)is, whatever the chosen way of dealing with
EMF validation and build, eventually you have to generate. When this happens
EBM's promise is to relieve the workspace to the extent possible, with smart
dependency tracking and putting resource-locks on only the provisional
extension of the build process of the dirty models. This means, putting lock
only on the list of models in the dirty models and java package namespace of
the gemodels.
6) One of the nice features of the workspace resource locks is, say you are
working on a chanin of models. After some editing, you save your work, which
is where the builder kicks in. It certainly works in the background and as
long as you do not save an editor in the affected resources (chain of
dependency and genmodel java artifacts), further save blocks the UI if the
build is still going on. Here the user has option which includes
i) revertion the save request, which will go back to the editing domain
ii) Can halt the builder and postpone the build process altogether to a
futher time
7) Since the validation and generation do not modify the model resources
this has minimal impact on post-build dirt-editor merge.
One of the interesting outcome of my test with a sample workspace with 5
interdependent ecore + genmodel is while normally it takes about few
secconds to generate a genmodel, the whole process takes 2 times of that
time. I guess, this is due to, CPU caching and less processing and stack
operation due to less resortion to UI both in terms of painting and going
all the way down to OS UI bindings.
I am well aware of the cost of nature/builder integration for a relatively
large EMF workspace. But this is / can become a -no-longer-a-thread by
i) Smart handling of the models (Hey after all we arfe dealing with the
models right, which is exactly for this very reason)
2) Computers and processors evolved drastically since the introduction of
EMF. (that is about 8-10x) [1] [2]
Regards,
Hasan
[1] http://www.cpubenchmark.net/high_end_cpus.html
[2] http://www.cpubenchmark.net/low_end_cpus.html
Ed Merks wrote:
> Hasan,
>
> This posting only has your CV, but I found it in one of your other cross
> posts.
>
> I think that the extremely well hidden generator wizard addresses many
> of these concerns though there's certainly room for improvements:
>
> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
generate-my-28.html
>
> An issue I see with defining a builder is that it involves defining a
> project nature which is something we've avoided in the core so far.
> Automatically performing actions that can be fairly expensive, such as
> validating all the Ecore models in the workspace, or generating all the
> GenModels in the workspace, is also something I'd be reluctant about.
> I suppose if it's done in the background, it's not such a concern. I
> wonder how much of the benefit could achieved by enhancing the
> GenerateHandler, e.g., to make it launch a job instead of blocking the
> IDE?
>
>
> Hasan Ceylan wrote:
>> The PDF has been attached...
>>
>>
>>> Hello,
>>>
>>> Attached is the PDF version of the forementioned EMF Build Manager
>>> Project Proposal.
>>>
>>> I kindly ask EMF community members and EMF (and subprojects) committers
>>> to review the document and forward their thoughts.
>>>
>>> I am also looking for mentors for the proposal.
>>>
>>> Below is the extraction of "Background" of the project. Please remember
>>> to review the attached PDF for full proposal draft.
>>>
>>> I apoligize for crossposting...
>>>
>>> ============================================================ =
>>> BACKGROUND
>>>
>>> EMF has been around for a long time. But the fact is that it lacked the
>>> necessary IDE Build Manager integration ever since.
>>> We think, the current code generation and validation toolset is below
>>> eclipse UI quality standards and fell behind similar facility provisions
>>> from the other projects.
>>>
>>> For instance, given the current infrastructure, if a developer is
>>> working with two ecore models that are dependent each other along with
>>> their respective genmodel, when developer makes a change in the base
>>> model that requires a change in the dependent ecore model, will need
>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>> executions along with several clicks to locate the action and run them.
>>>
>>> Also during the generation process, the UI is blocked and having
>>> finished the change on the base ecore, the developer cannot continue
>>> working on the second ecore before the base model generation finishes.
>>> Further more there is also need to switch to genmodels twice and
>>> initiate generation delibarately.
>>>
>>> In addition to this, if developer would like to validate the model in
>>> between the unit of the works, that will require clicks to locate the
>>> validation action, click to run the action and click to dismiss the
>>> feedback.
>>>
>>> It is also in our experience that the genmodel editors are kept open
>>> just for triggering code genration. Furthermore, this not only clutters
>>> the editor folder with unneeded editors, but also breaks the 'editor'
>>> description for genmodel, as usualy once genmodels are set up, they very
>>> seldom change, but needed to be open for code generation.
>>> When used on large workspaces with more than a few model, problem
>>> becomes a real burden.
>>>
>>> This is where EBM steps in and delegates much of the work to background
>>> build manager and prevents user distrubition with using the instruments
>>> like
>>> auto build on resource save, Marker and Problem View instrumentation to
>>> provide feedback.
>>> ============================================================ =
>>>
>>> Regards,
>>>
>>>
>>
>>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618970 is a reply to message #511391] |
Thu, 04 February 2010 07:20 |
| Eclipse User |
|
|
|
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 #618974 is a reply to message #512211] |
Fri, 05 February 2010 03:53 |
| Eclipse User |
|
|
|
Hello Sven,
Would love to test with Xtext + EMF Index bench.
Would you be so kind to give me directions to set up a development bench?
Regards,
Hasan
Sven Efftinge wrote:
> Hi Hasan,
>
> how is this idea related to Xtext's builder infrastructure and EMF
> index? It seems to be a perfect match for what you want to achieve.
>
> Cheers,
> Sven
>
> Hasan Ceylan schrieb:
>> Hello Ed,
>>
>> Thanks for sharing you comments. I will surely take a look at referenced
>> wizard / builder.
>>
>> I think the project will handle situations like this well enough since:
>> 1) It has built-in support for dependency chain, meaning only the
>> affected models in the change chain is marked for validation & generation
>> 2) It is not a must, to have the nature to have an EMF project, since you
>> can add / remove the nature by project->right click
>> 3) Builder triggers on save rather then "working-copy".
>> 4) This can further be improved by adding a grace-period and / or
>> max-depth configuration. Meaning, consecutive changes to models within a
>> time window will gather changes and start the *real* build only after the
>> grace period expires. Reaching of *Max-depth* can place a mark on the
>> status bar as well as putting validation markers on the
>> affected-but-yet-processed resources. Clicking on the status bar
>> notification or quick fix on the markers, can trigger partition or deal
>> with the rest of the process. 5) An unavoidable requirement of working
>> with (even for XX number of projects in a single workspace)is, whatever
>> the chosen way of dealing with EMF validation and build, eventually you
>> have to generate. When this happens EBM's promise is to relieve the
>> workspace to the extent possible, with smart dependency tracking and
>> putting resource-locks on only the provisional extension of the build
>> process of the dirty models. This means, putting lock only on the list of
>> models in the dirty models and java package namespace of the gemodels.
>> 6) One of the nice features of the workspace resource locks is, say you
>> are working on a chanin of models. After some editing, you save your
>> work, which is where the builder kicks in. It certainly works in the
>> background and as long as you do not save an editor in the affected
>> resources (chain of dependency and genmodel java artifacts), further save
>> blocks the UI if the build is still going on. Here the user has option
>> which includes i) revertion the save request, which will go back to the
>> editing domain ii) Can halt the builder and postpone the build process
>> altogether to a futher time
>> 7) Since the validation and generation do not modify the model resources
>> this has minimal impact on post-build dirt-editor merge.
>>
>>
>> One of the interesting outcome of my test with a sample workspace with 5
>> interdependent ecore + genmodel is while normally it takes about few
>> secconds to generate a genmodel, the whole process takes 2 times of that
>> time. I guess, this is due to, CPU caching and less processing and stack
>> operation due to less resortion to UI both in terms of painting and going
>> all the way down to OS UI bindings.
>>
>> I am well aware of the cost of nature/builder integration for a
>> relatively large EMF workspace. But this is / can become a
>> -no-longer-a-thread by i) Smart handling of the models (Hey after all we
>> arfe dealing with the models right, which is exactly for this very
>> reason) 2) Computers and processors evolved drastically since the
>> introduction of EMF. (that is about 8-10x) [1] [2]
>>
>> Regards,
>> Hasan
>>
>> [1] http://www.cpubenchmark.net/high_end_cpus.html
>> [2] http://www.cpubenchmark.net/low_end_cpus.html
>>
>>
>> Ed Merks wrote:
>>
>>> Hasan,
>>>
>>> This posting only has your CV, but I found it in one of your other cross
>>> posts.
>>>
>>> I think that the extremely well hidden generator wizard addresses many
>>> of these concerns though there's certainly room for improvements:
>>>
>>> http://thegordian.blogspot.com/2009/08/emf-tips-1-how-hell-d o-i-
>> generate-my-28.html
>>> An issue I see with defining a builder is that it involves defining a
>>> project nature which is something we've avoided in the core so far.
>>> Automatically performing actions that can be fairly expensive, such as
>>> validating all the Ecore models in the workspace, or generating all the
>>> GenModels in the workspace, is also something I'd be reluctant about.
>>> I suppose if it's done in the background, it's not such a concern. I
>>> wonder how much of the benefit could achieved by enhancing the
>>> GenerateHandler, e.g., to make it launch a job instead of blocking the
>>> IDE?
>>>
>>>
>>> Hasan Ceylan wrote:
>>>> The PDF has been attached...
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> Attached is the PDF version of the forementioned EMF Build Manager
>>>>> Project Proposal.
>>>>>
>>>>> I kindly ask EMF community members and EMF (and subprojects)
>>>>> committers to review the document and forward their thoughts.
>>>>>
>>>>> I am also looking for mentors for the proposal.
>>>>>
>>>>> Below is the extraction of "Background" of the project. Please
>>>>> remember to review the attached PDF for full proposal draft.
>>>>>
>>>>> I apoligize for crossposting...
>>>>>
>>>>> ============================================================ =
>>>>> BACKGROUND
>>>>>
>>>>> EMF has been around for a long time. But the fact is that it lacked
>>>>> the necessary IDE Build Manager integration ever since.
>>>>> We think, the current code generation and validation toolset is below
>>>>> eclipse UI quality standards and fell behind similar facility
>>>>> provisions from the other projects.
>>>>>
>>>>> For instance, given the current infrastructure, if a developer is
>>>>> working with two ecore models that are dependent each other along with
>>>>> their respective genmodel, when developer makes a change in the base
>>>>> model that requires a change in the dependent ecore model, will need
>>>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>>>> executions along with several clicks to locate the action and run
>>>>> them.
>>>>>
>>>>> Also during the generation process, the UI is blocked and having
>>>>> finished the change on the base ecore, the developer cannot continue
>>>>> working on the second ecore before the base model generation finishes.
>>>>> Further more there is also need to switch to genmodels twice and
>>>>> initiate generation delibarately.
>>>>>
>>>>> In addition to this, if developer would like to validate the model in
>>>>> between the unit of the works, that will require clicks to locate the
>>>>> validation action, click to run the action and click to dismiss the
>>>>> feedback.
>>>>>
>>>>> It is also in our experience that the genmodel editors are kept open
>>>>> just for triggering code genration. Furthermore, this not only
>>>>> clutters the editor folder with unneeded editors, but also breaks the
>>>>> 'editor' description for genmodel, as usualy once genmodels are set
>>>>> up, they very seldom change, but needed to be open for code
>>>>> generation. When used on large workspaces with more than a few model,
>>>>> problem becomes a real burden.
>>>>>
>>>>> This is where EBM steps in and delegates much of the work to
>>>>> background build manager and prevents user distrubition with using the
>>>>> instruments like
>>>>> auto build on resource save, Marker and Problem View instrumentation
>>>>> to provide feedback.
>>>>> ============================================================ =
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>
>>
>
>
--
Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647
From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."
--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618977 is a reply to message #512459] |
Fri, 05 February 2010 04:20 |
| Eclipse User |
|
|
|
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 #618982 is a reply to message #618979] |
Fri, 05 February 2010 05:09 |
| Eclipse User |
|
|
|
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 #618985 is a reply to message #618982] |
Fri, 05 February 2010 06:16 |
| Eclipse User |
|
|
|
Sven,
This sounds cool too, and definitely related. I wonder if something of
general utility like this makes sense to separate out from Xtext itself?
Sven Efftinge wrote:
> Hasan Ceylan schrieb:
>> The aim of EMF Builder is to validate and generate java artifacts on
>> ecore, xmi and genmodel based on changes on the resources. Basically
>> automates what you would do when you have an ecore and a genodel:
>> 1) Change the ecore
>> 2) open genmodel
>> 3) Issue generate all
>>
>> and does this with the dependencies considered (validates and
>> generates the dependent models)
>>
>> XText does this automatically with the mwe runner. Are you suggesting
>> integrating the xtext mwe into EMFBuilder so that the generation is
>> automated? I just couldn't get it, sorry
>
> No, I didn't meant anything MWE related. I was talking of the new
> builder infraststructure in Xtext.
> It is just exactly what you have in mind. It listenes on resource
> changes (is triggered on save), it computes the transtive hull of
> affected resources, it validates the affected resources and it
> provides two extension points:
> 1) one to register EMF-based languages (they don't have to be Xtext
> languages) (e.g. *.ecore, *.genmodel)
> 2) one to register participants, which can do arbitrary work based on
> the outcome of a build. (E.g. to start the generation of any affected
> genmodels and epackages).
>
> I have blogged about the builder infrastructure in general:
> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>
> The participant hook had been introduced with M5 and is demoed on the
> new & noteworthy page.
>
> Cheers,
> Sven
>
>
>>
>> Hasan
>>
>> Sven Efftinge wrote:
>>
>>> With Xtext M5 it is basically a matter of
>>> a) implementing and registering IResourceServiceProvider for ecore and
>>> genmodel. This makes sure that ecore and genmodel are indexed. It also
>>> provides the needed hook to compute the transitive hull of changes.
>>>
>>> b) implementing and registering IBuildParticipant.
>>> This one get's a call after each build passed in the
>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>> code generation.
>>>
>>> There's a short video demonstrating the second hook in our n&n document
>>> see M5/ProjectBuilder
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>> Sven
>>>
>>> Hasan Ceylan schrieb:
>>>> Hello Sven,
>>>>
>>>> Would love to test with Xtext + EMF Index bench.
>>>>
>>>> Would you be so kind to give me directions to set up a development
>>>> bench?
>>>>
>>>> Regards,
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hi Hasan,
>>>>>
>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>
>>>>> Cheers,
>>>>> Sven
>>>>>
>> <SNIP>
>>
>
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618988 is a reply to message #618985] |
Fri, 05 February 2010 10:01 |
| Eclipse User |
|
|
|
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 #618991 is a reply to message #512597] |
Sat, 06 February 2010 12:33 |
| Eclipse User |
|
|
|
Hi Hasan, Sven, Ed,
wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.
Sven
Am 05.02.2010 16:01, schrieb Sven Efftinge:
> Yes, I think it definitely makes sense at some point.
> Maybe we should work on extracting that functionality during the next
> release train?
>
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> This sounds cool too, and definitely related. I wonder if something
>> of general utility like this makes sense to separate out from Xtext
>> itself?
>>
>> Sven Efftinge wrote:
>>> Hasan Ceylan schrieb:
>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>> Basically automates what you would do when you have an ecore and a
>>>> genodel:
>>>> 1) Change the ecore
>>>> 2) open genmodel
>>>> 3) Issue generate all
>>>>
>>>> and does this with the dependencies considered (validates and
>>>> generates the dependent models)
>>>>
>>>> XText does this automatically with the mwe runner. Are you
>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>> generation is automated? I just couldn't get it, sorry
>>>
>>> No, I didn't meant anything MWE related. I was talking of the new
>>> builder infraststructure in Xtext.
>>> It is just exactly what you have in mind. It listenes on resource
>>> changes (is triggered on save), it computes the transtive hull of
>>> affected resources, it validates the affected resources and it
>>> provides two extension points:
>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>> languages) (e.g. *.ecore, *.genmodel)
>>> 2) one to register participants, which can do arbitrary work based
>>> on the outcome of a build. (E.g. to start the generation of any
>>> affected genmodels and epackages).
>>>
>>> I have blogged about the builder infrastructure in general:
>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>
>>> The participant hook had been introduced with M5 and is demoed on
>>> the new & noteworthy page.
>>>
>>> Cheers,
>>> Sven
>>>
>>>
>>>>
>>>> Hasan
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> With Xtext M5 it is basically a matter of
>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>> and
>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>> also
>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>
>>>>> b) implementing and registering IBuildParticipant.
>>>>> This one get's a call after each build passed in the
>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>> code generation.
>>>>>
>>>>> There's a short video demonstrating the second hook in our n&n
>>>>> document
>>>>> see M5/ProjectBuilder
>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>
>>>>>
>>>>> Sven
>>>>>
>>>>> Hasan Ceylan schrieb:
>>>>>> Hello Sven,
>>>>>>
>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>
>>>>>> Would you be so kind to give me directions to set up a
>>>>>> development bench?
>>>>>>
>>>>>> Regards,
>>>>>> Hasan
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hi Hasan,
>>>>>>>
>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>> <SNIP>
>>>>
>>>
>>>
>
>
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #618993 is a reply to message #512710] |
Sat, 06 February 2010 12:56 |
| Eclipse User |
|
|
|
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--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619406 is a reply to message #512721] |
Sat, 06 February 2010 13:17 |
| Eclipse User |
|
|
|
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 #619408 is a reply to message #512710] |
Sat, 06 February 2010 13:29 |
| Eclipse User |
|
|
|
Hello Sven,
First you may find the proposal draft here:
http://ebm.batoo.org/index.php/Main_Page
and, yes I definitely target a cycle with the dependencies resolved both in
the workspace and emf registry, and any change / error flag transitively
will affect the downstream models.
Frankly I hadn't though about caching all the extension from the registry. I
should add that as an enhancement request.
Hasan
Sven Krause wrote:
> Hi Hasan, Sven, Ed,
>
> wouldn't it make sense to have such an background build/gen job not only
> limited to ecore/gen/xtext? The most emf based models are registered
> with its package factory and the potential file extension. So it should
> be easily possible to identify each kind of model of model files within
> the marked projects and launch the generic validate/build build hook for
> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
> a special case. PS:the change of a base model might/should trigger the
> dependent model build cycle too.
>
> Sven
>
> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>> Yes, I think it definitely makes sense at some point.
>> Maybe we should work on extracting that functionality during the next
>> release train?
>>
>> Sven
>>
>> Ed Merks schrieb:
>>> Sven,
>>>
>>> This sounds cool too, and definitely related. I wonder if something
>>> of general utility like this makes sense to separate out from Xtext
>>> itself?
>>>
>>> Sven Efftinge wrote:
>>>> Hasan Ceylan schrieb:
>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>> Basically automates what you would do when you have an ecore and a
>>>>> genodel:
>>>>> 1) Change the ecore
>>>>> 2) open genmodel
>>>>> 3) Issue generate all
>>>>>
>>>>> and does this with the dependencies considered (validates and
>>>>> generates the dependent models)
>>>>>
>>>>> XText does this automatically with the mwe runner. Are you
>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>> generation is automated? I just couldn't get it, sorry
>>>>
>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>> builder infraststructure in Xtext.
>>>> It is just exactly what you have in mind. It listenes on resource
>>>> changes (is triggered on save), it computes the transtive hull of
>>>> affected resources, it validates the affected resources and it
>>>> provides two extension points:
>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>> languages) (e.g. *.ecore, *.genmodel)
>>>> 2) one to register participants, which can do arbitrary work based
>>>> on the outcome of a build. (E.g. to start the generation of any
>>>> affected genmodels and epackages).
>>>>
>>>> I have blogged about the builder infrastructure in general:
>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>
>>>> The participant hook had been introduced with M5 and is demoed on
>>>> the new & noteworthy page.
>>>>
>>>> Cheers,
>>>> Sven
>>>>
>>>>
>>>>>
>>>>> Hasan
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> With Xtext M5 it is basically a matter of
>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>> and
>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>> also
>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>
>>>>>> b) implementing and registering IBuildParticipant.
>>>>>> This one get's a call after each build passed in the
>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>> code generation.
>>>>>>
>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>> document
>>>>>> see M5/ProjectBuilder
>>>>>>
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>
>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>> development bench?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>> Hi Hasan,
>>>>>>>>
>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sven
>>>>>>>>
>>>>> <SNIP>
>>>>>
>>>>
>>>>
>>
>>
--
Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647
From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."
--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619409 is a reply to message #619408] |
Sun, 07 February 2010 04:33 |
| Eclipse User |
|
|
|
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 #619411 is a reply to message #512722] |
Sun, 07 February 2010 04:35 |
| Eclipse User |
|
|
|
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 #619413 is a reply to message #619409] |
Sun, 07 February 2010 09:38 |
| Eclipse User |
|
|
|
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--
|
|
|
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619417 is a reply to message #619413] |
Mon, 08 February 2010 01:56 |
| Eclipse User |
|
|
|
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 #619421 is a reply to message #619409] |
Mon, 08 February 2010 01:58 |
| Eclipse User |
|
|
|
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 #619426 is a reply to message #619421] |
Mon, 08 February 2010 06:33 |
| Eclipse User |
|
|
|
Sven,
Yes, I'd prefer to see the "generic" indexing be part of the index
project. Do you think support for triggered activities such as builds
or validation should be part of the index project as well?
Sven Efftinge wrote:
> See my other reply in this thread.
> I think such a functionality belongs to the EMF Index project.
>
> Sven
>
> Sven Krause schrieb:
>> Hi Hasan, Sven
>>
>> we have similar capabilities in the flowr project that became base of
>> the new mtf eclipse project. Are you interested to join the project and
>> bring your features into mtf? Or do you prefer to keep it standalone
>> (@Ed, Sven)?
>>
>> Sven
>> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>>> Hello Sven,
>>>
>>> First you may find the proposal draft here:
>>> http://ebm.batoo.org/index.php/Main_Page
>>>
>>> and, yes I definitely target a cycle with the dependencies resolved
>>> both in the workspace and emf registry, and any change / error flag
>>> transitively will affect the downstream models.
>>>
>>> Frankly I hadn't though about caching all the extension from the
>>> registry. I should add that as an enhancement request.
>>>
>>> Hasan
>>>
>>> Sven Krause wrote:
>>>
>>>
>>>> Hi Hasan, Sven, Ed,
>>>>
>>>> wouldn't it make sense to have such an background build/gen job not
>>>> only
>>>> limited to ecore/gen/xtext? The most emf based models are registered
>>>> with its package factory and the potential file extension. So it
>>>> should
>>>> be easily possible to identify each kind of model of model files
>>>> within
>>>> the marked projects and launch the generic validate/build build
>>>> hook for
>>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is
>>>> just
>>>> a special case. PS:the change of a base model might/should trigger the
>>>> dependent model build cycle too.
>>>>
>>>> Sven
>>>>
>>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>>
>>>>> Yes, I think it definitely makes sense at some point.
>>>>> Maybe we should work on extracting that functionality during the next
>>>>> release train?
>>>>>
>>>>> Sven
>>>>>
>>>>> Ed Merks schrieb:
>>>>>
>>>>>> Sven,
>>>>>>
>>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>>> of general utility like this makes sense to separate out from Xtext
>>>>>> itself?
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>>> genodel:
>>>>>>>> 1) Change the ecore
>>>>>>>> 2) open genmodel
>>>>>>>> 3) Issue generate all
>>>>>>>>
>>>>>>>> and does this with the dependencies considered (validates and
>>>>>>>> generates the dependent models)
>>>>>>>>
>>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>>
>>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>>> builder infraststructure in Xtext.
>>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>>> affected resources, it validates the affected resources and it
>>>>>>> provides two extension points:
>>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>>> affected genmodels and epackages).
>>>>>>>
>>>>>>> I have blogged about the builder infrastructure in general:
>>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>>
>>>>>>>
>>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>>> the new & noteworthy page.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>>> a) implementing and registering IResourceServiceProvider for
>>>>>>>>> ecore
>>>>>>>>> and
>>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>>> also
>>>>>>>>> provides the needed hook to compute the transitive hull of
>>>>>>>>> changes.
>>>>>>>>>
>>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>>> This one get's a call after each build passed in the
>>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to
>>>>>>>>> trigger
>>>>>>>>> code generation.
>>>>>>>>>
>>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>>> document
>>>>>>>>> see M5/ProjectBuilder
>>>>>>>>>
>>>>>>>>>
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>>
>>>>>>>>>> Hello Sven,
>>>>>>>>>>
>>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>>
>>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>>> development bench?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hasan
>>>>>>>>>>
>>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Hasan,
>>>>>>>>>>>
>>>>>>>>>>> how is this idea related to Xtext's builder infrastructure
>>>>>>>>>>> and EMF
>>>>>>>>>>> index? It seems to be a perfect match for what you want to
>>>>>>>>>>> achieve.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Sven
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
>
|
|
| |
| Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619430 is a reply to message #512966] |
Mon, 08 February 2010 08:51 |
| Eclipse User |
|
|
|
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 #619432 is a reply to message #619413] |
Mon, 08 February 2010 18:55 |
| Eclipse User |
|
|
|
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--
|
|
|
Goto Forum:
Current Time: Tue Nov 04 10:15:02 EST 2025
Powered by FUDForum. Page generated in 0.13263 seconds |
Home