Home » Modeling » TMF (Xtext) » Migrating from Oaw Xtext to TMF Xtext
| Migrating from Oaw Xtext to TMF Xtext [message #43122] |
Wed, 06 May 2009 12:58  |
Eclipse User |
|
|
|
Hi all,
We have open sourced Mod4j (mod4j.org) last April 1st. We have been very
busy with this, and are now looking into the Galileo release and specifically
into the new TMF Xtext, but also the Eclipse Xpand/Xtend/Checks and the
MWE components.
I have read through the TMF reference and can see that there are many
improvements being made making TMF more flexible then Oaw Xtext.
To see whether we should migrate to TMF and what work is involved I have
compiled a list of issues that are of importance to us.
The following issues seem to be simple.
1. We use an existing Ecore meta model, which seems to be ok, this is
neatly supported by TMF.
2. All grammar constructs from Oaw Xtext are supported by TMF Xtext,
modulo a few syntactic changes (like “import” instead of “preventMMGeneratrion”)
3. An Eclipse editor is generated
4. Xtend, Xpand and Checks are basically the same in Oaw, so I don’t
expect any problems there (Am I right?)
The next issues seem to be more work and I have some questions that
I hope someone might be able to answer:
1. We use (slightly adapted versions) of the generated New DSl Project and New Dsl File
wizards that were generated by Oaw Xtext, I don’t see any of these wizards being
generated by TMF Xtext. As these wizards are important to lower the barrier for our
users it would be a loss if they were not generated anymore. We can of course write
our own wizards from scratch, but that is more work, which we need to plan. Do you
plan to add the wizard generation to TMF Xtext ?
2. The MWE syntax seems to be different from the Oaw modeling workflow syntax (at least
I see “fragment” instead of “component” and many path names are at least different.
How big is the difference ? I have tried the documentation and FAQ links in the MWE wiki,
but end up in an empty page. Are the changes described anywhere?
3. We have integrated the running of workflows into the Eclipse builder. For this we start
the workflow engine programmatically from Java. I see no documentation on how this should
be done with MWE. This is a crucial issue for us, because the workflow must be run within
the same JVM as Eclipse, because that is where the CrossX broker is running.
4. We have mavenized running the workflow as well as integrated it into Eclipse. Do you
(plan to) provide any support for the use of maven to run workflows?
5. We have not been able to run the Xtext generator from Maven, will this become possible in TMF Xtext ?
6. The Oaw Xtext generator cleans the src-gen directory. It also clean all of the SVN information
there which confuses SVN. Of course we should not have to put the src-gen into SVN, but we have to
because of the previous issue (running Xtext generator from maven). Is this something that you
plan to resolve?
7. Writing your own code completion proposals was done through Xtend functions in Oaw Xtext. In
the documentation (and the example project I did) of TMF Xtext I see only the possibility to do
this through Java, in a way that looks quite different at first sight. As we have invested a lot
of effort to provide customized code completion this seems a lot of work for us. Are there
plans to also support the use of Xtend functions for proposals? Apart from the fact that this \
would be handy for us, using Xtend also makes it much easier and much less work to write you
own proposals.
In the feature map of TMF Xtext versus Oaw Xtext there is an X with the issue
“Xtend API for Code Completion”, but I can’t find it documentend anywhere.
Greeting, Jos
|
|
|
| Re: Migrating from Oaw Xtext to TMF Xtext [message #43156 is a reply to message #43122] |
Wed, 06 May 2009 14:06  |
| Eclipse User |
|
|
|
Hi Jos,
Jos Warmer schrieb:
> The following issues seem to be simple.
>
> 1. We use an existing Ecore meta model, which seems to be ok, this is
> neatly supported by TMF.
> 2. All grammar constructs from Oaw Xtext are supported by TMF Xtext,
> modulo a few syntactic changes (like “import” instead of “preventMMGeneratrion”)
> 3. An Eclipse editor is generated
> 4. Xtend, Xpand and Checks are basically the same in Oaw, so I don’t
> expect any problems there (Am I right?)
Yes, the languages havn't changed.
>
> The next issues seem to be more work and I have some questions that
> I hope someone might be able to answer:
> 1. We use (slightly adapted versions) of the generated New DSl Project and New Dsl File
> wizards that were generated by Oaw Xtext, I don’t see any of these wizards being
> generated by TMF Xtext. As these wizards are important to lower the barrier for our
> users it would be a loss if they were not generated anymore. We can of course write
> our own wizards from scratch, but that is more work, which we need to plan. Do you
> plan to add the wizard generation to TMF Xtext ?
Yes, we already have some rough prototypes and think we can improve
them. I'm not sure if they will be included in every Xtext DSL by
default in the final release, but the corresponding generator fragments
(TMF Xtext's generator is composable using so called fragments) will be
shipped so one can easily add this to the workflow.
Anyway, you could also easily create (and contribute) your own fragments
(shouldn't be too much work in the case of wizards), in case the thinks
we do in the area don't meet your expectations.
> 2. The MWE syntax seems to be different from the Oaw modeling workflow syntax (at least
> I see “fragment” instead of “component” and many path names are at least different.
> How big is the difference ? I have tried the documentation and FAQ links in the MWE wiki,
> but end up in an empty page. Are the changes described anywhere?
The language has not been changed. The fragments are not language
concepts but library concepts : The Xtext generator component is
configured with instances of IGeneratorFragment, which are injected into
XtextGenerator.addFragment(IGeneratorFragment) (hence the <fragment />
elements.
> 3. We have integrated the running of workflows into the Eclipse builder. For this we start
> the workflow engine programmatically from Java. I see no documentation on how this should
> be done with MWE. This is a crucial issue for us, because the workflow must be run within
> the same JVM as Eclipse, because that is where the CrossX broker is running.
One of the few things we changed in MWE is making the Java API to invoke
workflows more convenient.
With MWE you'll have to write something like this:
new WorkflowFacade("my/path/to/Workflow.mwe").run();
> 4. We have mavenized running the workflow as well as integrated it into Eclipse. Do you
> (plan to) provide any support for the use of maven to run workflows?
We've just checked in pom.xml for the various bundles and plan to make
them available somewhere (maybe ibiblio ?).
AFAIK the workflow plugin for m2 from fornax has not yet been migrated
to MWE.
> 5. We have not been able to run the Xtext generator from Maven, will this become possible in TMF Xtext ?
Yes, we already tried that. Works without changing the workflows. :-)
> 6. The Oaw Xtext generator cleans the src-gen directory. It also clean all of the SVN information
> there which confuses SVN. Of course we should not have to put the src-gen into SVN, but we have to
> because of the previous issue (running Xtext generator from maven). Is this something that you
> plan to resolve?
We've fixed the DirectoryCleaner in M2T. So that SVN files won't be deleted.
Also you can decide whether and how you want to delete the source-gen
folder as it is not included in the generator workflow shipped with TMF
Xtext. However, the project wizard creates an MWE file which uses the
directory cleaner.
> 7. Writing your own code completion proposals was done through Xtend functions in Oaw Xtext. In
> the documentation (and the example project I did) of TMF Xtext I see only the possibility to do
> this through Java, in a way that looks quite different at first sight. As we have invested a lot
> of effort to provide customized code completion this seems a lot of work for us. Are there
> plans to also support the use of Xtend functions for proposals? Apart from the fact that this \
> would be handy for us, using Xtend also makes it much easier and much less work to write you
> own proposals.
> In the feature map of TMF Xtext versus Oaw Xtext there is an X with the issue
> “Xtend API for Code Completion”, but I can’t find it documentend anywhere.
We strongly recommend to use the Java-based APIs. They are equally
convenient but much more flexible and debuggable. Also Java-based
implementations are factors faster then Xtend based implementations.
Performance is especially critical for the linking and scoping as well
as validation. OAW Xtext editors don't scale because these things have
usually been implemented in Xtend.
That said, we have Xtend-based APIs (not documented yet), which are
similar to the ones from oAW Xtext but not directly compatible.
The same applies for all other aspects: We have convenient, flexible,
scalable Java-Based interfaces and provide similar Xtend-based APIs in
addition. We expect that people will see the advantages in the Java APIs
(at least we do, although as you know I have a strong relationship with
Xtend).
Cheers,
Sven
|
|
|
| Re: Migrating from Oaw Xtext to TMF Xtext [message #43172 is a reply to message #43156] |
Thu, 07 May 2009 05:21 |
| Eclipse User |
|
|
|
Sven Efftinge bracht volgend idée uit :
> Hi Jos,
>
> Jos Warmer schrieb:
>
<... removed stuff...>
>> 2. The MWE syntax seems to be different from the Oaw modeling workflow
>> syntax (at least
>> I see “fragment” instead of “component” and many path names are at least
>> different.
>> How big is the difference ? I have tried the documentation and FAQ
>> links in the MWE wiki,
>> but end up in an empty page. Are the changes described anywhere?
>
> The language has not been changed. The fragments are not language concepts
> but library concepts : The Xtext generator component is configured with
> instances of IGeneratorFragment, which are injected into
> XtextGenerator.addFragment(IGeneratorFragment) (hence the <fragment />
> elements.
Ok, but to udnerrstand and use the MWE, I need tio udnersatdn the
library concepts. Is there any documentation available on this?
>
<... removed stuff...>
>
>> 5. We have not been able to run the Xtext generator from Maven, will this
>> become possible in TMF Xtext ?
>
> Yes, we already tried that. Works without changing the workflows. :-)
>
Great ! Can you point to an example of how to do this ?
>> 6. The Oaw Xtext generator cleans the src-gen directory. It also clean all
>> of the SVN information
>> there which confuses SVN. Of course we should not have to put the
>> src-gen into SVN, but we have to
>> because of the previous issue (running Xtext generator from maven). Is
>> this something that you
>> plan to resolve?
>
> We've fixed the DirectoryCleaner in M2T. So that SVN files won't be deleted.
> Also you can decide whether and how you want to delete the source-gen folder
> as it is not included in the generator workflow shipped with TMF Xtext.
> However, the project wizard creates an MWE file which uses the directory
> cleaner.
>
Good, we just need to change the MWE file and the problem is solved.
>> 7. Writing your own code completion proposals was done through Xtend
>> functions in Oaw Xtext. In
>> the documentation (and the example project I did) of TMF Xtext I see
>> only the possibility to do
>> this through Java, in a way that looks quite different at first sight.
>> As we have invested a lot
>> of effort to provide customized code completion this seems a lot of work
>> for us. Are there
>> plans to also support the use of Xtend functions for proposals? Apart
>> from the fact that this \
>> would be handy for us, using Xtend also makes it much easier and much
>> less work to write you
>> own proposals.
>> In the feature map of TMF Xtext versus Oaw Xtext there is an X with the
>> issue
>> “Xtend API for Code Completion”, but I can’t find it documentend
>> anywhere.
>
> We strongly recommend to use the Java-based APIs. They are equally convenient
> but much more flexible and debuggable. Also Java-based implementations are
> factors faster then Xtend based implementations.
> Performance is especially critical for the linking and scoping as well as
> validation. OAW Xtext editors don't scale because these things have usually
> been implemented in Xtend.
>
> That said, we have Xtend-based APIs (not documented yet), which are similar
> to the ones from oAW Xtext but not directly compatible.
>
> The same applies for all other aspects: We have convenient, flexible,
> scalable Java-Based interfaces and provide similar Xtend-based APIs in
> addition. We expect that people will see the advantages in the Java APIs (at
> least we do, although as you know I have a strong relationship with Xtend).
>
I see the point that Java is faster. However that is not really a
languagee feature, but more an impklementation fature. As far as I can
telle it is possible to translate Xtend expression to Java and compile
these, giving you the same speed as a native Java method ... and the
convenience to use the much more expressive Xtend language to write you
navigations throughb the model :-).
> Cheers,
> Sven
Jos
|
|
| | |
| Re: Migrating from Oaw Xtext to TMF Xtext [message #43542 is a reply to message #43449] |
Fri, 08 May 2009 02:47 |
| Eclipse User |
|
|
|
Hi,
Porter schrieb:
>
>
>> 1. We use an existing Ecore meta model, which seems to be ok, this is
>> neatly supported by TMF.
>
> The problem is that you'll be able to get the xtext editor working as
> long as you import the generated Epackage or Ecore for the existing
> metamodel by configuring the workflow file (search this list or see also
> the MWE section in Rich Gronback's excellent GMF/modelling book), but
> you may find it very difficult to get an xPand template or xtend
> template to work in conjunction with it to create a compiler. Haven't
> tried an interpreter in this situation.
Why is that difficult?
>
> In other words :
> - Xpand/xtend will generally work in conjunction with Xtext if you only
> use Xtext metamodel inference.
> - Xpand/xtend won't or may not work properly if your Xtext model
> includes metamodel inference and an imported Ecore/EMF model. They won't
> or may not detect the metamodels even if you get the xtext part working
> and even if you copy all the ecore models to the xpand folder.
I'm not aware of such problems...
>
> See these bugs/patches:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269635
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269596
These bugs are not directly related.
Anyway, I've fixed/closed them.
> If anyone has had any success in getting a complete tool chain working
> consisting of:
> - Import EMF/Ecore model in xtext, combined with
> - metalmodel inference in Xtext, then
> - Xpand and xtend models referencing the xtext model.
> then I'd be happy to hear how you did it.
I did. :-)
As this is a thing often asked for, I'll try to come up with a short
description of how to do this within the next weeks.
Regards,
Sven
|
|
| |
Goto Forum:
Current Time: Thu Jul 10 09:57:32 EDT 2025
Powered by FUDForum. Page generated in 0.07940 seconds |
Home