Part of my project is analyzing the structure of programs processed by the interpreter that I'm working to enhance. Xtext and the related tools from oAW allowed me to define a subset of the language for analysis and code generation. As there's a need for more function (and hopefully more speed), it's great that a new Xtext is available for Eclipse Galileo.
The reference for Xtext includes a section on changes from oAW to TMF that's quite informative, but doesn't include any advice on how to change the existing Eclipse projects. That's in the Eclipsepedia wiki section on Xtext Migration.
The guide is a bit ominous-sounding when it talks about specifying the language name in the Xtext project wizard. Since the previous name for my package wasn't very good, and there is very little extension work in the previous project—the main purpose is the generator—the approach for the moment is to copy the text into the shells created by the project wizard. The wizard doesn't give much advice about the naming, but the editor complains if the last element of the language name is lowercase.
In the old oAW system, the plugin added a context menu named 'generate Xtext artifacts'. This doesn't appear anymore. Since I'm building my eclipse configuration from the 'Classic SDK', it's necessary to install the Modeling Workflow Engine (MWE) separately. The MWE is required to run the workflow GenerateLanguageName.mwe in the parser project.
As the documentation says, unlike oAW, TMF Xtext doesn't enable parser backtracking by default. I was able to restructure the grammar rules to get rid of many of the warning(200) … Decision can match input such as "'whatever'" using multiple alternatives messages. (These aren't really warnings, since the resulting parser is ignoring portions of the grammar that I'm specifying). In the end, I found that there is a construct in the legacy language accepted by its recursive interpreter that's indeterminate. So I modified the Xtext MWE file as recommended by Sebastian Zarnekow to replace AntlrDelegatingFragment with XtextAntlrGeneratorFragment and DelegatingGeneratorFragment with XtextAntlrUiGeneratorFragment adding the child <options backtrack="true"/> element to each (don't remove the JavaBasedContentAssistFragment). I wonder if Xtext provides (or will provide) a way to enable backtracking for a subset of the grammar rules.
Once the Grammar was compiling again, I was able to check it out quickly by following the steps suggested in the Getting Started with Xtext post by Peter Friese. Invoking 'Run As → Eclipse Application' from the context menu of the parser project brings up a new IDE in a separate, initially empty, workspace. From there, create a new project and within that a new file with the extension named in the Xtext Wizard. Copying an existing program populated the outline view—a vast improvement over oAW which ate all the heap so the outline had to be disabled. One caveat: with the generated plugin configured, the editor is sure to fail with an NPE if you open a file named with the extension associated with your editor outside of a project (using File → Open).
Now, on to working with linkages in the AST!