Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619411 is a reply to message #512722] Sun, 07 February 2010 09:35 Go to previous messageGo to next message
Sven Krause is currently offline Sven KrauseFriend
Messages: 64
Registered: July 2009
Member
Hi Sven,

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

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

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

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
A separate builder project seems like a good thing.&nbsp; It seems closely
related to the Sphinx proposal as well, so it might make sense for it
to be part of that too...<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:hkm1dc$1js$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Hasan, Sven

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

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

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

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

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

Hasan

Sven Krause wrote:


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

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

Sven

Am 05.02.2010 16:01, schrieb Sven Efftinge:

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

Sven

Ed Merks schrieb:

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

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

Sven Efftinge wrote:

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

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

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

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

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

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

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

Cheers,
Sven



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

Sven Efftinge wrote:


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

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

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


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

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

Hasan Ceylan schrieb:

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

Would love to test with Xtext + EMF Index bench.

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

Regards,
Hasan

Sven Efftinge wrote:


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

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

Cheers,
Sven


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


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

--------------050704030205090700090909--


Ed Merks
Professional Support: https://www.macromodeling.com/
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 06:56 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
I think it's clearly in the scope of the EMF Index project.
See http://www.eclipse.org/proposals/emf-index/

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

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

Cheers,
Sven

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


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619419 is a reply to message #619411] Mon, 08 February 2010 06:57 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
Sven Krause schrieb:
> Hi Sven,
>
> doesn't put this construct extra effort in allowing trigger builds on
> any model or did use this explicit as filter?

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

Sven

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
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 06:58 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
See my other reply in this thread.
I think such a functionality belongs to the EMF Index project.

Sven

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


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619423 is a reply to message #619419] Mon, 08 February 2010 08:14 Go to previous messageGo to next message
Sven Krause is currently offline Sven KrauseFriend
Messages: 119
Registered: July 2009
Senior Member
Hi Sven,

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

Sven

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

Cheers,
Sven

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


--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
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 11:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Sven,

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


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


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619428 is a reply to message #512929] Mon, 08 February 2010 13:00 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Sven,
>
> Yes, I'd prefer to see the "generic" indexing be part of the index
> project. Do you think support for triggered activities such as builds
> or validation should be part of the index project as well?

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

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

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

Sven

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
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 13:51 Go to previous messageGo to next message
Hasan Ceylan is currently offline Hasan CeylanFriend
Messages: 198
Registered: July 2009
Senior Member
Sven & Ed,

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

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

Hasan

Sven Efftinge wrote:

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

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

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

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

Sven Krause wrote:=20
Hi Hasan, Sven

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

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

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

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

will affect the downstream models.

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

Hasan

Sven Krause wrote:

=20
Hi Hasan, Sven, Ed,

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

Sven

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

Sven

Ed Merks schrieb:
=20
Sven,

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

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

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

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

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

Cheers,
Sven


=20
Hasan

Sven Efftinge wrote:

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

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

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

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

=20
Sven

Hasan Ceylan schrieb:
=20
Hello Sven,

Would love to test with Xtext + EMF Index bench.

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

Regards,
Hasan

Sven Efftinge wrote:

=20
Hi Hasan,

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

Cheers,
Sven

=20
<SNIP>

=20
=20
=20
=20
=20

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

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

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

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

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

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

will affect the downstream models.

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

Hasan

Sven Krause wrote:

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

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

Sven

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

Sven

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

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

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

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

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

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

Cheers,
Sven


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

Sven Efftinge wrote:

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

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

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

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

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

Would love to test with Xtext + EMF Index bench.

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

Regards,
Hasan

Sven Efftinge wrote:

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

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

Cheers,
Sven

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

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

------=_NextPart_000_0036_01CAA922.83FABBB0--
Previous Topic:Appeal for review from modeling community to review EMF Build Manager Project Proposal
Next Topic:[Announce] Eclipse/OMG Symposium 2010
Goto Forum:
  


Current Time: Fri Mar 29 07:50:20 GMT 2024

Powered by FUDForum. Page generated in 0.03021 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top