XText2 采用和迁移
这里有人尝试采用 xtext2 并从 xtext1.x 迁移到 xtext2.0 吗？ 看来 xtext2 带来了许多新的有吸引力的功能。例如《可重用表达式语言》和《Xtend：代码生成语言》。 Xtext 工作台和重命名功能进行了许多性能增强。那么有人告诉你有关 xtext2 的经验吗？也许这是一个有点早的问题。但我只是拭目以待。
Does anyone here try to adopt xtext2 and migrate from xtext1.x to xtext2.0?
It seems xtext2 brings many new atractive features. Such as A Reusable Expression Language and Xtend: A Code Generation Language . Many performance enhancement is made to the Xtext workbench and rename capability. So any one tell you experence about xtext2? Probably this is a bit early question. But I just wait and see.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将现有的不太复杂的语言从 Xtext 1 更新到 Xtext 2，并尝试使用 Xtext2 和 XBase 开发一种新的语言。我必须重新运行代码生成步骤，并且还必须修改手写的验证器，因为错误和警告位置将使用文字而不是整数来指定。例如
error("文件不存在路径：" + path, fileReference, ViatraTestDslPackage.FILE__PATH);将替换为
error("文件不存在路径：" + path , ViatraTestDslPackage.Literals.FILE__PATH);同样，工作流程也必须更改以纳入一些新功能：大纲 API 使用不同的片段（outline.OutlineTreeProviderFragment和outline.QuickOutlineFragment），为了重命名和比较支持，将添加新片段（refactoring.RefactorElementNameFragment和compare.CompareFragment）。
根据我对 XBase 的实验，将其添加到已经支持某种表达式的语言中可能会耗费大量人力，因为必须用 XBase 表达式替换旧表达式（或者至少以某种方式进行更改以使其可用）在 XBase 表达式中），否则您必须在代码生成器或解释器中维护两种表达式支持。
总结我的回答，我相信，如果您有一个简单的 Xtext 1.0 编辑器，并且主要依赖于自动生成的功能，那么迁移到 Xtext 2.0 似乎很容易并且值得推荐；但是，如果您在手动编写的代码中自定义了很多东西，请小心，因为迁移可能不是直截了当的，而且我没有找到真正的迁移指南。
I updated an existing, not too complex language from Xtext 1 to Xtext 2, and tried to develop a new one using Xtext2 and XBase. I had to re-run the code generation step, and also had to modify the hand-written validators, because the error and warnings locations are to be specified using literals instead of integers. E.g.
error("File does not exist with path: " + path, fileReference, ViatraTestDslPackage.FILE__PATH);is to be replaced with
error("File does not exist with path: " + path, ViatraTestDslPackage.Literals.FILE__PATH);Similarly, the workflow has to be changed as well to incorporate some new features: the outline API uses different fragments (outline.OutlineTreeProviderFragment and outline.QuickOutlineFragment), for rename and compare support new fragments are to be added (refactoring.RefactorElementNameFragment and compare.CompareFragment).
With my experiments of XBase it seems, that adding that to a language that already supported some kind of expressions can be labour-intensive, because either old expressions has to be replaced with XBase expressions (or at least altered in a way to make them available in XBase expressions), otherwise you have to maintain two kind of expression support in your code generator or interpreter.
To conclude my answer, I believe, if you have a simple Xtext 1.0 editor, where you mostly relied on the automatically generated features, migrating to Xtext 2.0 seems easy and recommended; however, if you customized a lot of things in manually written code, be careful, because the migration might not be straight-forward, and I have found no real migration guide.
http://www.eclipse.org/Xtext/documentation/2_0_0/213-migrating-from-1.0.php#migrating_from_1_0_x_5_4
我刚刚发现这个有用的链接。
我也确实遇到了一些问题，特别是在序列化模块中。幸运的是，在 mwe2 文件中，它留下了 1.0 版序列化，我使用它并修复了使用 2.0 版序列化模块时的问题。不知道为什么..
另一个问题是 xtext 验证中有一个奇怪的错误。它总是抱怨 ClassCastException。从 String 转换为 QualifiedName 错误。
http://www.eclipse.org/Xtext/documentation/2_0_0/213-migrating-from-1.0.php#migrating_from_1_0_x_5_4
I just find this useful link.
Also I do meet some problem especially in serialization module. Luckily in mwe2 file, it leaves a version 1.0 serialization, i use that and fix the problem when using version 2.0 serialization module. Not knowing why..
Another problem is there is a strange bug in the xtext validation. It always complain about ClassCastException. cast from String to QualifiedName error.
考虑到最近的发布日期，现在还为时过早：
该团队刚刚在上个月的演示营中展示/演示了 XTend2 （2011 年 6 月）。
It is still early considering the recent release date:
The team have just presented/demo'ed XTend2 in democamps during last month (June 2011).