Migrating the OCL project to the new Xtext generator workflow. #2113
Comments
|
By Ed Willink on May 11, 2020 08:18 I've certainly considered migration for OCL and QVTd, but it's a possibly non-trivial no-fun activity that hasn't actually needed doing and which required too many strange Xtend things that I didn't understand. Given that Xtend is now deprecated, I'm not sure that migrating to the new infra is sensible. I'll wait till the no-Xtend infrastructure is available. I would be more inclined to migrate if the new serializer fixed the problem with comment indentation, but the MWE2/Xtext editor exhibits exactly the same poor functionality as my editors. (There is the seven year old Bug 405184 that shows that not even Xtext is migrating.) The MWE2 scripts can be found in the org.eclipse.ocl.examples.build and org.eclipse.qvtd.build plugins; all 8 editor scripts are 'identical'. |
|
By Tamas Miklossy on May 11, 2020 13:57 Thank for the feedback regarding the formatter issues. I created the following issues to keep track of the efforts: https://github.com/eclipse/xtext-core/issues/1489\ |
|
By Tamas Miklossy on May 19, 2020 06:42 The necessary steps on how to do such a migration is described in https://www.typefox.io/blog/xtexts-new-generator-migration |
|
By Ed Willink on May 20, 2020 03:28 (In reply to Tamas Miklossy from comment #3)
I see two major problems. It appears that the IDEA madness inflicts an extra *.ide plugin. Very very undesirable overhead given that I have at least 9 editors. I see no need for such bloat any more. It appears that Java code has to be converted to Xtend albeit using a wizard. This seems like a very bad idea now that Xtend is deprecated. The new infrastructure should have a much-less-Xtend mode. |
|
By Tamas Miklossy on May 20, 2020 03:44
Hints how to do that can be found under xatkit-bot-platform/xatkit-eclipse#29 genericIde = {
code = { |
|
By Ed Willink on Jun 12, 2020 03:49 I've managed to migrate the OCL parsers so that their tests passes. See workaround in Bug 564230. But the serialize tests fail since the new generator does not use the old formatter. See Bug 564229. Bug 564233 raised to make necessary fragment infrastrucrure unrestricted public API. Some of the UI tests work, amazingly including the single step debugging, but others stall on a do you want to add nature popup. The problem seems to be a UI/IDE Module chaos that needs greater insight to generate correctly. (In reply to Tamas Miklossy from comment #5)
The name hint is helpful and places all the ide packages to the ui plugin, but there are then two UI and IDE Modules that need consistent registration. One might expect that genericIde = { would redirect everything to use the old no-ide structure. Instead it gives an IOE becuase the folder for "ide" plugin is missing. |
|
By Ed Willink on Jun 12, 2020 04:57 The hint on eclipse/xtext-core#1489 gets the old formatter working. All standalone tests (parsing and serializing) now pass. Attempting to generate stubs for a new formatter hits: 25742 [main] ERROR ator.formatting.Formatter2Fragment2 - org.eclipse.xtext.xtext.generator.formatting.Formatter2Fragment2 has been configured to generate a Java stub, but that's not yet supported. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=481563 For which Bug 481563 makes it pretty clear that the new formatter is Xtend-only. Nopoint migrating to a deprecated functonality. Just the UI/IDE chaos to sort out. And a review of all the magic gragments such as formatter in the old mwe scripts that have just been arbitrarily lost. |
|
By Ed Willink on Jun 12, 2020 06:12 (In reply to Ed Willink from comment #7)
Eventually got some Xtend stubs and examined the Java equivalent. Ouch! Structurally it is better in that there are overrifeable merthods that do useful things rather than declarations, so wacky code/debugging might be possible. But by the time the Xtend is in Java it is seriously horrible to read the various format/+format overloads. Contrast with the simple visitXXXX overloads of the OCL autogenerated visitor framework. The old formatter uses a literal style on GrammarAccess that is not flexible but at least it's readable. Without Xtend, the new formatter seems to be one step forwards and five back. |
|
By Ed Willink on Jun 12, 2020 07:15 (In reply to Ed Willink from comment #7)
Easy. Just need to use the perversely named getEclipsePluginGenModule() to contribute to the "UI" plugin rather than getIdeGenModule() to the "IDE". All plugin tests pass. |
|
By Ed Willink on Jun 12, 2020 07:19 (In reply to Ed Willink from comment #8)
Now that the dispatch is on CS classes it might not be that hard to divert the root dispatch to a CSVisitor accept and do the traversal as visits. A few Java helper functions may solve the readability issues and be not so dissimilar to Xtend. |
|
By Ed Willink on Jun 12, 2020 10:30 (In reply to Ed Willink from comment #8)
Another one back: The old formatter uses many semantically sensitive method names such as a.getColonKeyword_9() which invariably go wrong after a grammar change forcing a revisit to the offending formatting section. The new formatter does keyword(";") which is not going to fail until run-time. |
|
By Ed Willink on Jun 26, 2020 03:06 (In reply to Ed Willink from comment #10)
The suggestion of a New Declarative Formatter in bug 564265 is looking promising. Formatting is based on idioms distributed to auto-generated meta-data rather than per-type overloads so no need for vistors / declarative dispatch. But perhaps the new formatter will only work for the core Xtext grammar functionality as used by OCL / QVTd. Too bad, users of the dark corners will have to do something else. AT least OCL comments will finally format correctly and we can replace the not very pleasant pretty-printer. |
|
By Ed Willink on Oct 18, 2021 16:27 (In reply to Ed Willink from comment #12)
This has been adopted for OCL/QVTd and provoked a reversion of the migration to the new framework. Retry the migration from commit 6d7bba7 |
|
By Ed Willink on Nov 15, 2023 10:42 See Bug 564265. Development reactivated and pushed to master for M3. |
|
By Ed Willink on Dec 04, 2023 10:42 Although released for 6.19.0 / 2023-12, not eveerything was perfect. In particular QVTd formatting was under-developed. Bug 582702 calls for more work on line wrapping. Bug 582703 calls for clearer/more useful locators. Bug 582704 calls for serialization replication to support variant matches. |
|
By Ed Willink on Dec 04, 2023 12:23 Bug 582705 tightens "- -1" |
|
By Ed Willink on Feb 26, 2024 04:51 The primary migration was done for 2023-12. 2024-03 has some fixes residual issues have distinct bugzillas. |
|
By Ed Willink on Feb 26, 2024 04:51 and resolved |
|
By Tamas Miklossy on Feb 26, 2024 04:56 Nice work Ed! |
| --- | --- |
| Bugzilla Link | 563046 |
| Status | RESOLVED FIXED |
| Importance | P3 normal |
| Reported | May 11, 2020 07:17 EDT |
| Modified | Feb 26, 2024 04:56 EDT |
| Depends on | 564229, 481563, 564233 |
| See also | 564230, 564265, 579108, 582702, 582703, 582704, 582705 |
| Reporter | Tamas Miklossy |
Description
As far as I can see, the OCL project is still based on the old Xtext generator infrastructure.
Since the Xtext team is planning to drop the entire support for the old Xtext generator:
eclipse/xtext-core#1485
it is recommended to update the OCL project to the new generator infrastructure.
Have you already considered such a migration?
In order to get a better overview about the entire work to be done, could you please enumerate the links to the current workflow files residing in the git repository of the OCL project?
Thanks!
Tamás
The text was updated successfully, but these errors were encountered: