Home » Modeling » TMF (Xtext) » [TMF][EMFatic] integration questions
|
| Re: [TMF][EMFatic] integration questions [message #7432 is a reply to message #7385] |
Thu, 27 March 2008 08:31   |
Eclipse User |
|
|
|
Originally posted by: sven.efftinge.de
Hi Lucas,
TMF consists of two solutions: TCS and Xtext.
Xtext has been developed at openArchitectureWare so far and will be
moved to TMF right after the next (final) release under oAW (oAW 4.3 to
be released in April).
We already have a textual notation to describe Ecore files, although it
hasn't been released so far. We were thinking of shipping it with Xtext
as a kind of Example, but maybe it would make sense to have it in Ecore
Tools.
Antlr 3 runtime is already IP approved. So for the Ecore DSL
implementation there are no IP issues. The Antlr 3 parser generator
still needs to be approved. The generator still uses StringTemplate
which is implemented using Antlr 2.x.
As Antlr 2.x won't be IP approved Terence Parr (the lead of Antlr) needs
to port things to Antlr 3. Last time I asked ( month ago) he said
sometime late summer/autumn.
regards,
Sven
lucas bigeardel wrote:
> Hi,
>
> I'm lucas from emft search/ecore tools. I recently proposed some help to
> get EMFatic build sat up + maybe porting EMFatic code from antlr 2.x to
> 3.x if compliant with EPL/IP.
>
> Now, I would like to know more about TMF. I suspect TMF and EMatic share
> some lot of features and was asking myself if there wasn't some action
> to take since Ecore Tools expressed its interest on integrating EMFatic
> in order to avoid overlaping.
>
> So my questions are :
>
> - What about feature overlaping between TMF and EMFatic ?
> - Does it sounds reasonible to get ecore textual notation from EMFatic
> or is it better to get it from TMF (if any)?
> - Is TMF code accessible somewhere on modeling.tmf cvs repo or elsewhere ?
>
> BTW, who knows about antlr 3.x EPL/IP compliancy for booth code &
> generated code ?
>
> regards,
>
> - Lucas
|
|
|
| Re: [TMF][EMFatic] integration questions [message #7453 is a reply to message #7432] |
Thu, 27 March 2008 09:35 |
 Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi Lucas,
Here is some additional information (mostly about TCS). I kept both your
questions and Sven answers. (Note that I am not sure my reordering makes
it better ;-).)
>> - What about feature overlaping between TMF and EMFatic ?
EMFatic is a textual syntax for Ecore. TMF lets you define textual
syntaxes for any metamodel.
> TMF consists of two solutions: TCS and Xtext.
> We already have a textual notation to describe Ecore files, although it
> hasn't been released so far. We were thinking of shipping it with Xtext
> as a kind of Example, but maybe it would make sense to have it in Ecore
> Tools.
TCS also comes with a textual syntax to specify metamodels, which is
called KM3. Please, let us know if you want more information or want to
discuss about the respective features of EMFatic and KM3.
It is also possible to re-implement EMFatic in TCS.
>> - Does it sounds reasonible to get ecore textual notation from EMFatic
I am not sure I understand your question, so please tell me if I do not
answer it properly.
The EMFatic syntax was specifically tailored for Ecore. Therefore, it is
probably as good as any textual syntax one could make for Ecore.
>> or is it better to get it from TMF (if any)?
About the implementation of EMFatic: it seems to make more sense to use
TMF than a specific approach. For instance, the Ecore diagram tool is
made using GMF, not directly GEF although it would be possible.
This being said, it is not my choice to make :-).
>> - Is TMF code accessible somewhere on modeling.tmf cvs repo or
>> elsewhere ?
> Xtext has been developed at openArchitectureWare so far and will be
> moved to TMF right after the next (final) release under oAW (oAW 4.3 to
> be released in April).
TCS is already a component of GMT, which will migrate to TMF soon.
Here is its current location:
http://www.eclipse.org/gmt/tcs/
You can notably find a library of syntaxes specified in TCS on eclipsepedia:
http://wiki.eclipse.org/TCS/Zoo
>> BTW, who knows about antlr 3.x EPL/IP compliancy for booth code &
>> generated code ?
> Antlr 3 runtime is already IP approved. So for the Ecore DSL
> implementation there are no IP issues. The Antlr 3 parser generator
> still needs to be approved. The generator still uses StringTemplate
> which is implemented using Antlr 2.x.
> As Antlr 2.x won't be IP approved Terence Parr (the lead of Antlr) needs
> to port things to Antlr 3. Last time I asked ( month ago) he said
> sometime late summer/autumn.
I did not know about the StringTemplate dependency. There is also
another dependency I am aware of: the grammar of ANTLRv3 is written in
ANTLRv2. Therefore, you need the jar of ANTLRv2 to use the ANTLRv3
parser generator.
As far as I know, the ANTLRv3 grammar in ANTLRv3 already exists, but is
not used in ANTLRv3 yet.
Regards,
Frédéric Jouault
|
|
| |
| Re: [TMF][EMFatic] integration questions [message #7508 is a reply to message #7497] |
Thu, 27 March 2008 23:34 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi Miguel,
>> About the implementation of EMFatic: it seems to make more sense to
>> use TMF than a specific approach. For instance, the Ecore diagram tool
>> is made using GMF, not directly GEF although it would be possible.
>
> That's a bit of an oversimplification of the feature set of Emfatic.
> Emfatic sports several non-generated UI goodies around generics. First
> of all, one can use Emfatic to define an .ecore model with generics.
> Additionally, Emfatic supports (a) visualizing the resulting type
> hierarchy in a dedicated view as well as (b) relying on hyperlink
> navigation and highlighting to correlate type arguments and their
> usages. Other non-generated UI goodies include validation on save,
> outline filters, hoovers to display declarations. The full list of
> current non-generated UI goodies can be found at
> http://www.sts.tu-harburg.de/~mi.garcia/SoC2007/Improvements ToTheEmfaticEditor.pdf
>
>
> We would lose all those hard earned features by letting loose any of TCS
> or xText on the Emfatic grammar ...
Thanks for reminding us about this. I tend to forget it ;-).
What I should have written is: *ideally*, Emfatic should be implemented
using TMF. Of course, this can only be done if/when:
1) TMF supports all required features.
OR
2) We are ready to add Emfatic-specific Java code, which I understand
also happens with GMF (although I do not know if the Ecore diagrams do
this).
I personally prefer 1), but it requires more features from TMF than 2).
Until then, I guess we (the TMF committers) could use Emfatic
feature-level as a goal, as we sometimes look at JDT.
Note:
It would be interesting to know exactly which features of Emfatic are
currently not supported by either xText or TMF. Indeed, it is not
because a given feature is "non-generated" in the current Emfatic
implementation that it is cannot be already supported by TMF.
Regards,
Frédéric Jouault
|
|
|
Goto Forum:
Current Time: Sun Oct 06 15:13:35 GMT 2024
Powered by FUDForum. Page generated in 2.72802 seconds |
] 
Search
Help
Register
Login
Home
