Home » Modeling » TMF (Xtext) » [TCS] IModelHandler
|
| Re: [TCS] IModelHandler [message #582 is a reply to message #569] |
Fri, 08 February 2008 16:48   |
 Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi Thibault,
> I am trying to create an alternative implementation of
> org.eclipse.gmt.tcs.injector.IModelHandler
>
> I could do with some more documentation of the methods, though I can
> guess most of it from looking at ASMModelHandler (or infer from the name).
> My main concern right now is public Set getElementsByType(String typeName);
>
> Should this also return all elements inheriting from the type?
Yes.
> Also, what is the intended difference between
> public void actualSet(Object ame_, String propertyName, Object value);
> and
> public void set(Object ame, String prop, Object value);
actualSet is used when we already have a model handler-specific value.
Actually, we should not need it if we were totally independent of the
model handler. This is not the case yet, but we are working on it.
Thanks for the feedback.
Regards,
Frédéric Jouault
|
|
|
| Re: [TCS] IModelHandler [message #595 is a reply to message #569] |
Thu, 14 February 2008 22:11 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi,
I thought you might want to know that the ModelHandler interface has
been improved.
It is now called ModelAdapter.
More importantly, TCSInjector has been split in TCSInjector, and
ParserLauncher. ParserLauncher does not depend on ASMModels. Therefore,
implementing a ModelAdapter for something else (e.g., directly EMF) is
much simpler.
Regards,
Frédéric Jouault
Thibault Kruse wrote:
> Hi,
>
> I am trying to create an alternative implementation of
> org.eclipse.gmt.tcs.injector.IModelHandler
>
> I could do with some more documentation of the methods, though I can
> guess most of it from looking at ASMModelHandler (or infer from the name).
> My main concern right now is public Set getElementsByType(String typeName);
>
> Should this also return all elements inheriting from the type?
>
> Also, what is the intended difference between
> public void actualSet(Object ame_, String propertyName, Object value);
> and
> public void set(Object ame, String prop, Object value);
>
>
> regards,
> Thibault
>
|
|
|
| Re: [TCS] IModelHandler [message #630 is a reply to message #595] |
Tue, 19 February 2008 09:20 |
T Kruse
Messages: 73
Registered: July 2009 |
Member |
|
|
Hi,
> I thought you might want to know that the ModelHandler interface has
> been improved.
> It is now called ModelAdapter.
I hope this is not the only improvement ;-).
Great, I'll check it out.
> More importantly, TCSInjector has been split in TCSInjector, and
> ParserLauncher. ParserLauncher does not depend on ASMModels. Therefore,
> implementing a ModelAdapter for something else (e.g., directly EMF) is
> much simpler.
Nice. What I would also need, for textual modeling, is having the grammar
generation be independent from ATL. I would not know any other suitable
Model Transformation language, but I would think that one does not need to
generate the ANTLR3 grammar using model transformation. Will you ever
encode the Transformation logic into java code, so that it may run
independently from the AMMAScripts? I would do so myself, but since I
cannot read the ATL, that would be hard to do.
thanks for the work,
Thibault
|
|
|
| Re: [TCS] IModelHandler [message #653 is a reply to message #630] |
Tue, 19 February 2008 17:37 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello,
If I understand correctly, you would like to have an Eclipse builder
(implemented in a specific plugin) to do the work instead of having to
use the ant scripts?
If this is what you mean, then this is about rewritting the ant part in
Java, not the ATL part.
Am I right?
Regards,
Frédéric Jouault
Thibault Kruse a écrit :
> Hi,
>
>> I thought you might want to know that the ModelHandler interface has
>> been improved.
>> It is now called ModelAdapter.
>
> I hope this is not the only improvement ;-). Great, I'll check it out.
>
>> More importantly, TCSInjector has been split in TCSInjector, and
>> ParserLauncher. ParserLauncher does not depend on ASMModels.
>> Therefore, implementing a ModelAdapter for something else (e.g.,
>> directly EMF) is much simpler.
>
> Nice. What I would also need, for textual modeling, is having the
> grammar generation be independent from ATL. I would not know any other
> suitable Model Transformation language, but I would think that one does
> not need to generate the ANTLR3 grammar using model transformation. Will
> you ever encode the Transformation logic into java code, so that it may
> run independently from the AMMAScripts? I would do so myself, but since
> I cannot read the ATL, that would be hard to do.
>
> thanks for the work,
> Thibault
>
|
|
|
| Re: [TCS] IModelHandler [message #665 is a reply to message #653] |
Wed, 20 February 2008 11:51 |
T Kruse
Messages: 73
Registered: July 2009 |
Member |
|
|
Hi,
>> What I would also need, for textual modeling, is having the
>> grammar generation be independent from ATL.
>
> If I understand correctly, you would like to have an Eclipse builder
> (implemented in a specific plugin) to do the work instead of having to
> use the ant scripts?
> If this is what you mean, then this is about rewritting the ant part in
> Java, not the ATL part.
I need to create an Injector injecting into MOF, not KM3, using a MOF DSL
metamodel, not a KM3 metamodel.
I believe right now, the injector creation ant tasks trigger some model
transformation that transforms the TCS model into an ANTLR model using
also the DSL metamodel. The way you do this now, I don't see a chance for
me to use MOF metamodels instead of KM3 models in your framework.
So what I would need is a way to replace all parts that depend on KM3
metamodels with MOF. And right now I believe that I would be unable to do
this reusing what is done by ATL, because I would not even know where to
start.
If the transformation was done in Java, I would more easily see how I
could substitue KM3 bits with MOF bits.
If the ant part were be rewritten in java, but the ATL part still (as far
as I can see) being dependent on KM3, I would still be unable to do my MOF
thing. I would like the ATL part being in Java so that I can see how the
transformation process interacts with the DSL metamodel, so I can decouple
this from KM3 and use MOF instead.
Maybe there is an obvious way to achieve what I need to do, so please
mention it if you know one.
thanks,
Thibault
|
|
|
| Re: [TCS] IModelHandler [message #2147 is a reply to message #665] |
Thu, 21 February 2008 06:50 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello,
> I need to create an Injector injecting into MOF, not KM3, using a MOF
> DSL metamodel, not a KM3 metamodel.
> I believe right now, the injector creation ant tasks trigger some model
> transformation that transforms the TCS model into an ANTLR model using
> also the DSL metamodel. The way you do this now, I don't see a chance
> for me to use MOF metamodels instead of KM3 models in your framework.
> So what I would need is a way to replace all parts that depend on KM3
> metamodels with MOF. And right now I believe that I would be unable to
> do this reusing what is done by ATL, because I would not even know where
> to start.
>
> If the transformation was done in Java, I would more easily see how I
> could substitue KM3 bits with MOF bits.
So, now I understand what you want to do. Your problem has nothing to do
with the way it is implemented, until you want to modify it. See below.
The first question is therefore: do you really need to modify it? The
answer is that TCS was designed to support what you describe, so you
should not need to modify it for this purpose.
Remark: if the transformation was done in Java, you would know the
language, but the code would probably be much more complex than it is
now. So, I am not convinced at all that it would be easier for you to
understand that Java code than to learn ATL.
> If the ant part were be rewritten in java, but the ATL part still (as
> far as I can see) being dependent on KM3, I would still be unable to do
> my MOF thing. I would like the ATL part being in Java so that I can see
> how the transformation process interacts with the DSL metamodel, so I
> can decouple this from KM3 and use MOF instead.
Of course. I only assumed this as a possible interpretation of your
previous post.
> Maybe there is an obvious way to achieve what I need to do, so please
> mention it if you know one.
A bit of history first: the first version of TCS (i.e., the TCS2ANTLR
transformation) was written so that it was taking a MOF 1.4 metamodel
instead of a KM3 metamodel. Then, when we added EMF support, we had to
support Ecore as well.
Instead of having n versions of TCS2ANTLR, we decided to use a typical
model engineering technique for this kind of situation: a pivot. KM3 is
this pivot.
Therefore, the way TCS supports Ecore, MOF, etc. is by requiring one
additional transformation per metametamodel, from this metametamodel to
KM3. The Ecore2KM3, and MOF2KM3 transformations are already available,
but you can also write other transformations as required.
With the current version of TCS, you always use a KM3 metamodel to build
the grammar, but the injection actually happens using either EMF and
Ecore or MDR and MOF 1.4.
Note that the pivot technique is not completely new either: it is very
close to intermediate languages used in traditional compilers.
Regards,
Frédéric Jouault
|
|
|
| Re: [TCS] IModelHandler [message #2174 is a reply to message #2147] |
Thu, 21 February 2008 07:09 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello again,
I forgot something: you can write that additional transformation from
your metametamodel to KM3 in Java or whatever other language.
I am still convinced that writting it in ATL will be more efficient, but
I cannot force you ;-).
Regards,
Frédéric Jouault
Frédéric Jouault a écrit :
> Hello,
>
>> I need to create an Injector injecting into MOF, not KM3, using a MOF
>> DSL metamodel, not a KM3 metamodel.
>> I believe right now, the injector creation ant tasks trigger some
>> model transformation that transforms the TCS model into an ANTLR model
>> using also the DSL metamodel. The way you do this now, I don't see a
>> chance for me to use MOF metamodels instead of KM3 models in your
>> framework.
>> So what I would need is a way to replace all parts that depend on KM3
>> metamodels with MOF. And right now I believe that I would be unable to
>> do this reusing what is done by ATL, because I would not even know
>> where to start.
>>
>> If the transformation was done in Java, I would more easily see how I
>> could substitue KM3 bits with MOF bits.
>
> So, now I understand what you want to do. Your problem has nothing to do
> with the way it is implemented, until you want to modify it. See below.
>
> The first question is therefore: do you really need to modify it? The
> answer is that TCS was designed to support what you describe, so you
> should not need to modify it for this purpose.
>
>
> Remark: if the transformation was done in Java, you would know the
> language, but the code would probably be much more complex than it is
> now. So, I am not convinced at all that it would be easier for you to
> understand that Java code than to learn ATL.
>
>
>> If the ant part were be rewritten in java, but the ATL part still (as
>> far as I can see) being dependent on KM3, I would still be unable to
>> do my MOF thing. I would like the ATL part being in Java so that I can
>> see how the transformation process interacts with the DSL metamodel,
>> so I can decouple this from KM3 and use MOF instead.
>
> Of course. I only assumed this as a possible interpretation of your
> previous post.
>
>
>> Maybe there is an obvious way to achieve what I need to do, so please
>> mention it if you know one.
>
> A bit of history first: the first version of TCS (i.e., the TCS2ANTLR
> transformation) was written so that it was taking a MOF 1.4 metamodel
> instead of a KM3 metamodel. Then, when we added EMF support, we had to
> support Ecore as well.
>
> Instead of having n versions of TCS2ANTLR, we decided to use a typical
> model engineering technique for this kind of situation: a pivot. KM3 is
> this pivot.
>
> Therefore, the way TCS supports Ecore, MOF, etc. is by requiring one
> additional transformation per metametamodel, from this metametamodel to
> KM3. The Ecore2KM3, and MOF2KM3 transformations are already available,
> but you can also write other transformations as required.
>
> With the current version of TCS, you always use a KM3 metamodel to build
> the grammar, but the injection actually happens using either EMF and
> Ecore or MDR and MOF 1.4.
>
>
> Note that the pivot technique is not completely new either: it is very
> close to intermediate languages used in traditional compilers.
>
>
>
>
> Regards,
>
> Frédéric Jouault
|
|
|
| Re: [TCS] IModelHandler [message #2204 is a reply to message #2147] |
Thu, 21 February 2008 10:24 |
T Kruse
Messages: 73
Registered: July 2009 |
Member |
|
|
Frédéric Jouault wrote:
> Hello,
>> I need to create an Injector injecting into MOF, not KM3, using a MOF
>> DSL metamodel, not a KM3 metamodel...
>
> The first question is therefore: do you really need to modify it? The
> answer is that TCS was designed to support what you describe, so you
> should not need to modify it for this purpose.
Right, that sounds encouraging, but I still don't know how to do this. I
currently believe something like I have to build an ant file, in this ant
file I would load my MOF metamodel, transform it into KM3 (the pivot),
have a TCS injector created.
I assume the current ant task doing the grammar creation is this:
<target name="TCS2ANTLR" depends="TCSCompilation">
<am3.atl path="${TCSToolkitLocation}ATL/TCS2ANTLR/TCS2ANTLR.asm">
<inModel name="IN" model="${metamodel}.tcs"/>
<inModel name="TCS" model="TCS"/>
<inModel name="MM" model="${metamodel}.km3"/>
<inModel name="KM3" model="KM3"/>
<inModel name="ANTLR" model="ANTLR"/>
<inmodel name="MOF" model="%EMF" />
<library name="KM3Helpers"
path="${TCSToolkitLocation}ATL/KM3Helpers/KM3Helpers.asm" />
<library name="strings"
path="${TCSToolkitLocation}ATL/strings/strings.asm" />
<outModel name="OUT" model="${metamodel}.g" metamodel="ANTLR"/>
</am3.atl>
<am3.saveModel model="${metamodel}.g"
path="${TCSFolderPath}${metamodel}.g">
<extractor name="ebnf">
<param name="format" value="ANTLR.tcs"/>
<param name="identEsc" value=""/>
<param name="indentString" value=" "/>
</extractor>
</am3.saveModel>
</target>
So I would have to change the line
<inModel name="MM" model="${metamodel}.km3"/>
to something else, and include some
am3.loadModel task before to somehow load my MOF metamodel.
However right now I don't understand the context enough to know what
exactly to write, and I don't know where to find any docu that would tell
me how. How can I find out?
If I somehow managed to do this, I could get an Injector and Extractor DSL
<-> KM3. I could either change the TCS Injector code to get something DSL
<-> MOF, or I could use KM3 <-> MOF here again each time I inject or
extract.
Since the ultimate goal is to create tool support for my DSL offering
features that go beyond generic text editor features, I don't think the
transformation approach would not be practicable. So I'd need a DSL <->
MOF Injector and Extractor, where the Injector could run in a text editor
in the background.
> Remark: if the transformation was done in Java, you would know the
> language, but the code would probably be much more complex than it is
> now. So, I am not convinced at all that it would be easier for you to
> understand that Java code than to learn ATL.
I can imagine this is true.
> With the current version of TCS, you always use a KM3 metamodel to build
> the grammar, but the injection actually happens using either EMF and
> Ecore or MDR and MOF 1.4.
Where can I specify this, where can I choose?
|
|
| |
| Re: [TCS] IModelHandler [message #2263 is a reply to message #2234] |
Thu, 21 February 2008 13:42 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Thibault a écrit :
>
>> Therefore, the way TCS supports Ecore, MOF, etc. is by requiring one
>> additional transformation per metametamodel, from this metametamodel
>> to KM3. The Ecore2KM3, and MOF2KM3 transformations are already
>> available, but you can also write other transformations as required.
>
> By the way, is there a way for me to look at the existing ATL
> transformations? The CVS projects only seem to contain .asm files, which
> I assumed to be compiled ATL. And I thought this was done to prevent
> people like me to look at the ATL.
>
The transformations are on the CVS. The simplest way to access them is
from the TCS Zoo: http://wiki.eclipse.org/TCS/Zoo
Regards,
Frédéric Jouault
|
|
|
| Re: [TCS] IModelHandler [message #2293 is a reply to message #2204] |
Thu, 21 February 2008 13:43 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello,
Could you please tell us what tools you are using, what versions of MOF,
etc?
Thanks,
Frédéric Jouault
Thibault a écrit :
> Frédéric Jouault wrote:
>
>> Hello,
>
>>> I need to create an Injector injecting into MOF, not KM3, using a MOF
>>> DSL metamodel, not a KM3 metamodel...
>>
>> The first question is therefore: do you really need to modify it? The
>> answer is that TCS was designed to support what you describe, so you
>> should not need to modify it for this purpose.
>
> Right, that sounds encouraging, but I still don't know how to do this. I
> currently believe something like I have to build an ant file, in this
> ant file I would load my MOF metamodel, transform it into KM3 (the
> pivot), have a TCS injector created.
> I assume the current ant task doing the grammar creation is this:
> <target name="TCS2ANTLR" depends="TCSCompilation">
> <am3.atl path="${TCSToolkitLocation}ATL/TCS2ANTLR/TCS2ANTLR.asm">
> <inModel name="IN" model="${metamodel}.tcs"/>
> <inModel name="TCS" model="TCS"/>
> <inModel name="MM" model="${metamodel}.km3"/>
> <inModel name="KM3" model="KM3"/>
> <inModel name="ANTLR" model="ANTLR"/>
> <inmodel name="MOF" model="%EMF" />
> <library name="KM3Helpers"
> path="${TCSToolkitLocation}ATL/KM3Helpers/KM3Helpers.asm" />
> <library name="strings"
> path="${TCSToolkitLocation}ATL/strings/strings.asm" />
> <outModel name="OUT" model="${metamodel}.g" metamodel="ANTLR"/>
> </am3.atl>
>
> <am3.saveModel model="${metamodel}.g"
> path="${TCSFolderPath}${metamodel}.g">
> <extractor name="ebnf">
> <param name="format" value="ANTLR.tcs"/>
> <param name="identEsc" value=""/>
> <param name="indentString" value=" "/>
> </extractor>
> </am3.saveModel>
> </target>
>
> So I would have to change the line
> <inModel name="MM" model="${metamodel}.km3"/>
> to something else, and include some am3.loadModel task before to somehow
> load my MOF metamodel.
> However right now I don't understand the context enough to know what
> exactly to write, and I don't know where to find any docu that would
> tell me how. How can I find out?
>
>
> If I somehow managed to do this, I could get an Injector and Extractor
> DSL <-> KM3. I could either change the TCS Injector code to get
> something DSL <-> MOF, or I could use KM3 <-> MOF here again each time I
> inject or extract. Since the ultimate goal is to create tool support for
> my DSL offering features that go beyond generic text editor features, I
> don't think the transformation approach would not be practicable. So I'd
> need a DSL <-> MOF Injector and Extractor, where the Injector could run
> in a text editor in the background.
>
>> Remark: if the transformation was done in Java, you would know the
>> language, but the code would probably be much more complex than it is
>> now. So, I am not convinced at all that it would be easier for you to
>> understand that Java code than to learn ATL.
>
> I can imagine this is true.
>
>> With the current version of TCS, you always use a KM3 metamodel to
>> build the grammar, but the injection actually happens using either EMF
>> and Ecore or MDR and MOF 1.4.
>
> Where can I specify this, where can I choose?
>
|
|
| | | |
| Re: [TCS] IModelHandler [message #2472 is a reply to message #2413] |
Fri, 22 February 2008 13:36 |
T Kruse
Messages: 73
Registered: July 2009 |
Member |
|
|
HI,
> Then, I suggest you build your parser using KM3 (translated from your
> MOF metamodel) and TCS.
> For translation from MOF to KM3, you may use whatever mechanism you want
> (even a plain Java program). You can even automate its execution by
> adding a call to it in the ant scripts.
> Then, the generated parser will be usable with MOF and your JMI
> implementation provided you implement the corresponding ModelAdapter.
Yes, I would like to do that, now. Using KM3 as pivot during parser
generation sounds fine. I am a little worried still about the "Problems"
model in TCSInjector, but apart from that I would like to do it as you say.
If I could have the build process be inside a builder and not having to
have AMMACore and AMMAScripts as projects in Eclipse, that would even be
nicer, of course, in a few month.
|
|
|
| Re: [TCS] IModelHandler [message #2499 is a reply to message #2472] |
Sat, 23 February 2008 14:22 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi,
> Yes, I would like to do that, now. Using KM3 as pivot during parser
> generation sounds fine. I am a little worried still about the "Problems"
> model in TCSInjector, but apart from that I would like to do it as you say.
The Problem metamodel is there because even error reports are models ;-).
> If I could have the build process be inside a builder and not having to
> have AMMACore and AMMAScripts as projects in Eclipse, that would even be
> nicer, of course, in a few month.
Actually, this is what the TCS builder plugin does. See the following
wiki page for more information:
http://wiki.eclipse.org/TCS/Language_Project
This builder has many advantages over the ant scripts: faster, better
integrated in Eclipse, etc.
Also, please note that CVS HEAD may not be working at the current time.
The reason is that TCS HEAD depends on a newer version of ATL (i.e., a
specific branch) than ATL HEAD. ATL HEAD is indeed in a stabilization
stage because of its simultaneous releases with Ganymede (i.e., Eclipse
3.4).
Regards,
Frédéric Jouault
|
|
|
Goto Forum:
Current Time: Fri Aug 16 17:05:59 GMT 2024
Powered by FUDForum. Page generated in 0.06013 seconds |
] 
Search
Help
Register
Login
Home
