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 |
Sven Krause Messages: 64 Registered: July 2009 |
Member |
|
|
Hi Sven,
doesn't put this construct extra effort in allowing trigger builds on
any model or did use this explicit as filter?
Sven
Am 06.02.2010 19:17, schrieb Sven Efftinge:
> Yes, Xtext's builder infrastructure is not specific to Xtext or ecore,
> but allows to "build" any kind of EMF resource in the workspace.
> However, we do not reuse the ResourceFactory.Registry.INSTANCE but
> have a Registry for so called IResourceServiceProviders.
> So if you want to have your EMF models built, just implement and
> register one.
>
> Cheers,
> Sven
>
> Ed Merks schrieb:
>> Sven,
>>
>> What the other Sven described sounded quite general along the lines
>> of what you're suggesting. It would certainly be good in such a
>> framework to make a validation cycle trivial to enable, i.e., just an
>> extension with a generic reusable validator trigger.
>>
>>
>> Sven Krause wrote:
>>> Hi Hasan, Sven, Ed,
>>>
>>> wouldn't it make sense to have such an background build/gen job not
>>> only
>>> limited to ecore/gen/xtext? The most emf based models are registered
>>> with its package factory and the potential file extension. So it should
>>> be easily possible to identify each kind of model of model files within
>>> the marked projects and launch the generic validate/build build hook
>>> for
>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>> a special case. PS:the change of a base model might/should trigger the
>>> dependent model build cycle too.
>>>
>>> Sven
>>>
>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>
>>>> Yes, I think it definitely makes sense at some point.
>>>> Maybe we should work on extracting that functionality during the next
>>>> release train?
>>>>
>>>> Sven
>>>>
>>>> Ed Merks schrieb:
>>>>
>>>>> Sven,
>>>>>
>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>> of general utility like this makes sense to separate out from Xtext
>>>>> itself?
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>> genodel:
>>>>>>> 1) Change the ecore
>>>>>>> 2) open genmodel
>>>>>>> 3) Issue generate all
>>>>>>>
>>>>>>> and does this with the dependencies considered (validates and
>>>>>>> generates the dependent models)
>>>>>>>
>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>
>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>> builder infraststructure in Xtext.
>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>> affected resources, it validates the affected resources and it
>>>>>> provides two extension points:
>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>> affected genmodels and epackages).
>>>>>>
>>>>>> I have blogged about the builder infrastructure in general:
>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>
>>>>>>
>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>> the new & noteworthy page.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>> and
>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>> also
>>>>>>>> provides the needed hook to compute the transitive hull of
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>> This one get's a call after each build passed in the
>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to
>>>>>>>> trigger
>>>>>>>> code generation.
>>>>>>>>
>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>> document
>>>>>>>> see M5/ProjectBuilder
>>>>>>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>
>>>>>>>>> Hello Sven,
>>>>>>>>>
>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>
>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>> development bench?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hasan
>>>>>>>>>
>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Hasan,
>>>>>>>>>>
>>>>>>>>>> how is this idea related to Xtext's builder infrastructure
>>>>>>>>>> and EMF
>>>>>>>>>> index? It seems to be a perfect match for what you want to
>>>>>>>>>> achieve.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>
>
|
|
|
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619413 is a reply to message #619409] |
Sun, 07 February 2010 14:38 |
Ed Merks 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. It seems closely
related to the Sphinx proposal as well, so it might make sense for it
to be part of that too...<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:hkm1dc$1js$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Hasan, Sven
we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?
Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Sven,
First you may find the proposal draft here:
<a class="moz-txt-link-freetext" href="http://ebm.batoo.org/index.php/Main_Page">http://ebm.batoo.org/index.php/Main_Page</a>
and, yes I definitely target a cycle with the dependencies resolved both in
the workspace and emf registry, and any change / error flag transitively
will affect the downstream models.
Frankly I hadn't though about caching all the extension from the registry. I
should add that as an enhancement request.
Hasan
Sven Krause wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Hasan, Sven, Ed,
wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.
Sven
Am 05.02.2010 16:01, schrieb Sven Efftinge:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?
Sven
Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Sven,
This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?
Sven Efftinge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hasan Ceylan schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">The aim of EMF Builder is to validate and generate java artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all
and does this with the dependencies considered (validates and
generates the dependent models)
XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
</pre>
</blockquote>
<pre wrap="">No, I didn't meant anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).
I have blogged about the builder infrastructure in general:
<a class="moz-txt-link-freetext" href=" http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html"> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html</a>
The participant hook had been introduced with M5 and is demoed on
the new & noteworthy page.
Cheers,
Sven
</pre>
<blockquote type="cite">
<pre wrap="">Hasan
Sven Efftinge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.
b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.
There's a short video demonstrating the second hook in our n&n
document
see M5/ProjectBuilder
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">(<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php"> http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php</a>)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Sven
Hasan Ceylan schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Sven,
Would love to test with Xtext + EMF Index bench.
Would you be so kind to give me directions to set up a
development bench?
Regards,
Hasan
Sven Efftinge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Hasan,
how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.
Cheers,
Sven
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><SNIP>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------050704030205090700090909--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619417 is a reply to message #619413] |
Mon, 08 February 2010 06:56 |
Sven Efftinge Messages: 1823 Registered: July 2009 |
Senior Member |
|
|
I think it's clearly in the scope of the EMF Index project.
See http://www.eclipse.org/proposals/emf-index/
"""
Define APIs and implement components for specifying search scopes,
collecting and persisting index data, synchronization of index data with
model changes, and querying of model elements.
"""
The Sphinx project seems to have a rather wide scope. I think we should
tune its scope a bit, but that belongs to a different thread (and
newsgroup).
Cheers,
Sven
Ed Merks schrieb:
> A separate builder project seems like a good thing. It seems closely
> related to the Sphinx proposal as well, so it might make sense for it to
> be part of that too...
>
> Sven Krause wrote:
>> Hi Hasan, Sven
>>
>> we have similar capabilities in the flowr project that became base of
>> the new mtf eclipse project. Are you interested to join the project and
>> bring your features into mtf? Or do you prefer to keep it standalone
>> (@Ed, Sven)?
>>
>> Sven
>> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>>
>>> Hello Sven,
>>>
>>> First you may find the proposal draft here:
>>> http://ebm.batoo.org/index.php/Main_Page
>>>
>>> and, yes I definitely target a cycle with the dependencies resolved both in
>>> the workspace and emf registry, and any change / error flag transitively
>>> will affect the downstream models.
>>>
>>> Frankly I hadn't though about caching all the extension from the registry. I
>>> should add that as an enhancement request.
>>>
>>> Hasan
>>>
>>> Sven Krause wrote:
>>>
>>>
>>>
>>>> Hi Hasan, Sven, Ed,
>>>>
>>>> wouldn't it make sense to have such an background build/gen job not only
>>>> limited to ecore/gen/xtext? The most emf based models are registered
>>>> with its package factory and the potential file extension. So it should
>>>> be easily possible to identify each kind of model of model files within
>>>> the marked projects and launch the generic validate/build build hook for
>>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>>> a special case. PS:the change of a base model might/should trigger the
>>>> dependent model build cycle too.
>>>>
>>>> Sven
>>>>
>>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>>
>>>>
>>>>> Yes, I think it definitely makes sense at some point.
>>>>> Maybe we should work on extracting that functionality during the next
>>>>> release train?
>>>>>
>>>>> Sven
>>>>>
>>>>> Ed Merks schrieb:
>>>>>
>>>>>
>>>>>> Sven,
>>>>>>
>>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>>> of general utility like this makes sense to separate out from Xtext
>>>>>> itself?
>>>>>>
>>>>>> Sven Efftinge wrote:
>>>>>>
>>>>>>
>>>>>>> Hasan Ceylan schrieb:
>>>>>>>
>>>>>>>
>>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>>> genodel:
>>>>>>>> 1) Change the ecore
>>>>>>>> 2) open genmodel
>>>>>>>> 3) Issue generate all
>>>>>>>>
>>>>>>>> and does this with the dependencies considered (validates and
>>>>>>>> generates the dependent models)
>>>>>>>>
>>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>>
>>>>>>>>
>>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>>> builder infraststructure in Xtext.
>>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>>> affected resources, it validates the affected resources and it
>>>>>>> provides two extension points:
>>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>>> affected genmodels and epackages).
>>>>>>>
>>>>>>> I have blogged about the builder infrastructure in general:
>>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>>
>>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>>> the new & noteworthy page.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hasan
>>>>>>>>
>>>>>>>> Sven Efftinge wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>>> and
>>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>>> also
>>>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>>>
>>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>>> This one get's a call after each build passed in the
>>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>>>> code generation.
>>>>>>>>>
>>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>>> document
>>>>>>>>> see M5/ProjectBuilder
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>>
>>>
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hello Sven,
>>>>>>>>>>
>>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>>
>>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>>> development bench?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hasan
>>>>>>>>>>
>>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Hasan,
>>>>>>>>>>>
>>>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Sven
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> <SNIP>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
|
|
| |
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619421 is a reply to message #619409] |
Mon, 08 February 2010 06:58 |
Sven Efftinge Messages: 1823 Registered: July 2009 |
Senior Member |
|
|
See my other reply in this thread.
I think such a functionality belongs to the EMF Index project.
Sven
Sven Krause schrieb:
> Hi Hasan, Sven
>
> we have similar capabilities in the flowr project that became base of
> the new mtf eclipse project. Are you interested to join the project and
> bring your features into mtf? Or do you prefer to keep it standalone
> (@Ed, Sven)?
>
> Sven
> Am 06.02.2010 19:29, schrieb Hasan Ceylan:
>> Hello Sven,
>>
>> First you may find the proposal draft here:
>> http://ebm.batoo.org/index.php/Main_Page
>>
>> and, yes I definitely target a cycle with the dependencies resolved both in
>> the workspace and emf registry, and any change / error flag transitively
>> will affect the downstream models.
>>
>> Frankly I hadn't though about caching all the extension from the registry. I
>> should add that as an enhancement request.
>>
>> Hasan
>>
>> Sven Krause wrote:
>>
>>
>>> Hi Hasan, Sven, Ed,
>>>
>>> wouldn't it make sense to have such an background build/gen job not only
>>> limited to ecore/gen/xtext? The most emf based models are registered
>>> with its package factory and the potential file extension. So it should
>>> be easily possible to identify each kind of model of model files within
>>> the marked projects and launch the generic validate/build build hook for
>>> them. The ecore build cycle (refresh genmodel, trigger codegen) is just
>>> a special case. PS:the change of a base model might/should trigger the
>>> dependent model build cycle too.
>>>
>>> Sven
>>>
>>> Am 05.02.2010 16:01, schrieb Sven Efftinge:
>>>
>>>> Yes, I think it definitely makes sense at some point.
>>>> Maybe we should work on extracting that functionality during the next
>>>> release train?
>>>>
>>>> Sven
>>>>
>>>> Ed Merks schrieb:
>>>>
>>>>> Sven,
>>>>>
>>>>> This sounds cool too, and definitely related. I wonder if something
>>>>> of general utility like this makes sense to separate out from Xtext
>>>>> itself?
>>>>>
>>>>> Sven Efftinge wrote:
>>>>>
>>>>>> Hasan Ceylan schrieb:
>>>>>>
>>>>>>> The aim of EMF Builder is to validate and generate java artifacts
>>>>>>> on ecore, xmi and genmodel based on changes on the resources.
>>>>>>> Basically automates what you would do when you have an ecore and a
>>>>>>> genodel:
>>>>>>> 1) Change the ecore
>>>>>>> 2) open genmodel
>>>>>>> 3) Issue generate all
>>>>>>>
>>>>>>> and does this with the dependencies considered (validates and
>>>>>>> generates the dependent models)
>>>>>>>
>>>>>>> XText does this automatically with the mwe runner. Are you
>>>>>>> suggesting integrating the xtext mwe into EMFBuilder so that the
>>>>>>> generation is automated? I just couldn't get it, sorry
>>>>>>>
>>>>>> No, I didn't meant anything MWE related. I was talking of the new
>>>>>> builder infraststructure in Xtext.
>>>>>> It is just exactly what you have in mind. It listenes on resource
>>>>>> changes (is triggered on save), it computes the transtive hull of
>>>>>> affected resources, it validates the affected resources and it
>>>>>> provides two extension points:
>>>>>> 1) one to register EMF-based languages (they don't have to be Xtext
>>>>>> languages) (e.g. *.ecore, *.genmodel)
>>>>>> 2) one to register participants, which can do arbitrary work based
>>>>>> on the outcome of a build. (E.g. to start the generation of any
>>>>>> affected genmodels and epackages).
>>>>>>
>>>>>> I have blogged about the builder infrastructure in general:
>>>>>> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
>>>>>>
>>>>>> The participant hook had been introduced with M5 and is demoed on
>>>>>> the new & noteworthy page.
>>>>>>
>>>>>> Cheers,
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hasan
>>>>>>>
>>>>>>> Sven Efftinge wrote:
>>>>>>>
>>>>>>>
>>>>>>>> With Xtext M5 it is basically a matter of
>>>>>>>> a) implementing and registering IResourceServiceProvider for ecore
>>>>>>>> and
>>>>>>>> genmodel. This makes sure that ecore and genmodel are indexed. It
>>>>>>>> also
>>>>>>>> provides the needed hook to compute the transitive hull of changes.
>>>>>>>>
>>>>>>>> b) implementing and registering IBuildParticipant.
>>>>>>>> This one get's a call after each build passed in the
>>>>>>>> IResourceDescription.Deltas. Based on that you'll be able to trigger
>>>>>>>> code generation.
>>>>>>>>
>>>>>>>> There's a short video demonstrating the second hook in our n&n
>>>>>>>> document
>>>>>>>> see M5/ProjectBuilder
>>>>>>>>
>>>>>>>>
>> ( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)
>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> Hasan Ceylan schrieb:
>>>>>>>>
>>>>>>>>> Hello Sven,
>>>>>>>>>
>>>>>>>>> Would love to test with Xtext + EMF Index bench.
>>>>>>>>>
>>>>>>>>> Would you be so kind to give me directions to set up a
>>>>>>>>> development bench?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hasan
>>>>>>>>>
>>>>>>>>> Sven Efftinge wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Hasan,
>>>>>>>>>>
>>>>>>>>>> how is this idea related to Xtext's builder infrastructure and EMF
>>>>>>>>>> index? It seems to be a perfect match for what you want to achieve.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
|
|
| | |
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619426 is a reply to message #619421] |
Mon, 08 February 2010 11:33 |
Ed Merks 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 #619430 is a reply to message #512966] |
Mon, 08 February 2010 13:51 |
Hasan Ceylan Messages: 198 Registered: July 2009 |
Senior Member |
|
|
Sven & Ed,
I have posted the beta release of EBM. I would appricate you comments and
reviews.
Having not aware of the EMF Index project, I developed an internal builder
state and dependency model (SDK has the code). We should revise that part if
necessary, by the way what is the state of EMF Index project?
Hasan
Sven Efftinge wrote:
> Ed Merks schrieb:
>> Sven,
>>
>> Yes, I'd prefer to see the "generic" indexing be part of the index
>> project. Do you think support for triggered activities such as builds
>> or validation should be part of the index project as well?
>
> Yes, I think so, because it is technically hard to separate between
> these things. A central mechanism which keeps the workspace in sync with
> the index, has everything we need to do validation and further post
> processing (like triggering code generation).
>
> The EMF index should of course *not* provide language specific
> implementations. For instance a GenModel execution for changes in ecore
> or genmodels, like Hassan proposed, clearly belongs elsewhere (e.g.
> EcoreTools).
>
> So far, all that stuff is located in Xtext's repository.
>
> Sven
>
|
|
|
Re: An appeal for modeling community review to new "EMF Build Manager Project" Proposal [message #619432 is a reply to message #619413] |
Mon, 08 February 2010 23:55 |
Yves YANG Messages: 688 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0036_01CAA922.83FABBB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It seems EGF has this capability. It is really a task orchestration =
system. We are investigating to use it in PMF.
Regards
Yves YANG
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:hkmj9d$kms$2@build.eclipse.org...
A separate builder project seems like a good thing. It seems closely =
related to the Sphinx proposal as well, so it might make sense for it to =
be part of that too...
Sven Krause wrote:=20
Hi Hasan, Sven
we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?
Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
Hello Sven,
First you may find the proposal draft here:
http://ebm.batoo.org/index.php/Main_Page
and, yes I definitely target a cycle with the dependencies resolved both =
in=20
the workspace and emf registry, and any change / error flag transitively =
will affect the downstream models.
Frankly I hadn't though about caching all the extension from the =
registry. I=20
should add that as an enhancement request.
Hasan
Sven Krause wrote:
=20
Hi Hasan, Sven, Ed,
wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.
Sven
Am 05.02.2010 16:01, schrieb Sven Efftinge:
=20
Yes, I think it definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?
Sven
Ed Merks schrieb:
=20
Sven,
This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?
=20
Sven Efftinge wrote:
=20
Hasan Ceylan schrieb:
=20
The aim of EMF Builder is to validate and generate java =
artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all
and does this with the dependencies considered (validates and
generates the dependent models)
XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
=20
No, I didn't meant anything MWE related. I was talking of =
the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).
I have blogged about the builder infrastructure in general:
http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.html
The participant hook had been introduced with M5 and is demoed on
the new & noteworthy page.
Cheers,
Sven
=20
Hasan
Sven Efftinge wrote:
=20
With Xtext M5 it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.
b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.
There's a short video demonstrating the second hook in our n&n
document
see M5/ProjectBuilder
=20
=
( http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not eworthy.php)=
=20
Sven
Hasan Ceylan schrieb:
=20
Hello Sven,
Would love to test with Xtext + EMF Index bench.
Would you be so kind to give me directions to set up a
development bench?
Regards,
Hasan
Sven Efftinge wrote:
=20
Hi Hasan,
how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.
Cheers,
Sven
=20
<SNIP>
=20
=20
=20
=20
=20
------=_NextPart_000_0036_01CAA922.83FABBB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff text=3D#000000>
<DIV><FONT size=3D2 face=3DArial>It seems EGF has this capability. It is =
really a=20
task orchestration system. We are investigating to use it in=20
PMF.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Regards</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>Yves YANG</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:hkmj9d$kms$2@build.eclipse.org">news:hkmj9d$kms$2@build.ecli=
pse.org</A>...</DIV>A=20
separate builder project seems like a good thing. It seems =
closely=20
related to the Sphinx proposal as well, so it might make sense for it =
to be=20
part of that too...<BR><BR>Sven Krause wrote:=20
<BLOCKQUOTE cite=3Dmid:hkm1dc$1js$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hi Hasan, Sven
we have similar capabilities in the flowr project that became base of
the new mtf eclipse project. Are you interested to join the project and
bring your features into mtf? Or do you prefer to keep it standalone
(@Ed, Sven)?
Sven
Am 06.02.2010 19:29, schrieb Hasan Ceylan:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello Sven,
First you may find the proposal draft here:
<A class=3Dmoz-txt-link-freetext =
href=3D"http://ebm.batoo.org/index.php/Main_Page">http://ebm.batoo.org/in=
dex.php/Main_Page</A>
and, yes I definitely target a cycle with the dependencies resolved both =
in=20
the workspace and emf registry, and any change / error flag transitively =
will affect the downstream models.
Frankly I hadn't though about caching all the extension from the =
registry. I=20
should add that as an enhancement request.
Hasan
Sven Krause wrote:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Hasan, Sven, Ed,
wouldn't it make sense to have such an background build/gen job not only
limited to ecore/gen/xtext? The most emf based models are registered
with its package factory and the potential file extension. So it should
be easily possible to identify each kind of model of model files within
the marked projects and launch the generic validate/build build hook for
them. The ecore build cycle (refresh genmodel, trigger codegen) is just
a special case. PS:the change of a base model might/should trigger the
dependent model build cycle too.
Sven
Am 05.02.2010 16:01, schrieb Sven Efftinge:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Yes, I think it =
definitely makes sense at some point.
Maybe we should work on extracting that functionality during the next
release train?
Sven
Ed Merks schrieb:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Sven,
This sounds cool too, and definitely related. I wonder if something
of general utility like this makes sense to separate out from Xtext
itself?
=20
Sven Efftinge wrote:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hasan Ceylan =
schrieb:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">The aim of EMF =
Builder is to validate and generate java artifacts
on ecore, xmi and genmodel based on changes on the resources.
Basically automates what you would do when you have an ecore and a
genodel:
1) Change the ecore
2) open genmodel
3) Issue generate all
and does this with the dependencies considered (validates and
generates the dependent models)
XText does this automatically with the mwe runner. Are you
suggesting integrating the xtext mwe into EMFBuilder so that the
generation is automated? I just couldn't get it, sorry
=20
</PRE></BLOCKQUOTE><PRE wrap=3D"">No, I didn't meant =
anything MWE related. I was talking of the new
builder infraststructure in Xtext.
It is just exactly what you have in mind. It listenes on resource
changes (is triggered on save), it computes the transtive hull of
affected resources, it validates the affected resources and it
provides two extension points:
1) one to register EMF-based languages (they don't have to be Xtext
languages) (e.g. *.ecore, *.genmodel)
2) one to register participants, which can do arbitrary work based
on the outcome of a build. (E.g. to start the generation of any
affected genmodels and epackages).
I have blogged about the builder infrastructure in general:
<A class=3Dmoz-txt-link-freetext =
href=3D" http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture=
..html"> http://blog.efftinge.de/2010/01/xtexts-new-builder-infrastru cture.=
html</A>
The participant hook had been introduced with M5 and is demoed on
the new & noteworthy page.
Cheers,
Sven
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hasan
Sven Efftinge wrote:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">With Xtext M5 =
it is basically a matter of
a) implementing and registering IResourceServiceProvider for ecore
and
genmodel. This makes sure that ecore and genmodel are indexed. It
also
provides the needed hook to compute the transitive hull of changes.
b) implementing and registering IBuildParticipant.
This one get's a call after each build passed in the
IResourceDescription.Deltas. Based on that you'll be able to trigger
code generation.
There's a short video demonstrating the second hook in our n&n
document
see M5/ProjectBuilder
=20
=
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BLOCKQUOTE></=
BLOCKQUOTE><PRE wrap=3D"">(<A class=3Dmoz-txt-link-freetext =
href=3D" http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not ewort=
hy.php"> http://www.eclipse.org/Xtext/documentation/0_8_0/new_and_not ewort=
hy.php</A>)
=20
</PRE>
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Sven
Hasan Ceylan schrieb:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello Sven,
Would love to test with Xtext + EMF Index bench.
Would you be so kind to give me directions to set up a
development bench?
Regards,
Hasan
Sven Efftinge wrote:
=20
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Hasan,
how is this idea related to Xtext's builder infrastructure and EMF
index? It seems to be a perfect match for what you want to achieve.
Cheers,
Sven
=20
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D""><SNIP>
=20
</PRE></BLOCKQUOTE><PRE wrap=3D""> =20
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""> =20
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""> =20
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0036_01CAA922.83FABBB0--
|
|
|
Goto Forum:
Current Time: Fri Mar 29 07:50:20 GMT 2024
Powered by FUDForum. Page generated in 0.03021 seconds
|