Hi Henrik
I was under the impression the plan was to standardize on Ring as the meta model to use; to replace ChangeRecord / MCDefinition. We do not know if ring is for replacing changeRecord. I'm not sure that we can. Ring is to have a representation of a program not the file representation of program (now may be we could extend it). We will extend it/improve to have a full compilation unit. Now Ring is about programs not file representation. We removed recently Pseudo* metamodel and FilePackage and the old tools to browse cs and st file. What we would like to do is to be able to remove RB program model to use Ring instead. But somebody has to help because we are full. However, after Ring as added to the image in 2011, no further work as been done to actually replace the ChangeRecord / MCDefinition use though, and I recently ran into Yet Another, new(ish)ly added, code model; the codeImport extraction/rewrite introduces a new CodeDeclaration + subclasses. There are different models: Codeimporter is a model of chunk format. (you know the ugly stuff where the parser is coded by hand....). Now we created a simple declaration entity hierarchy to avoid to have isKindOf and other uglies everywhere.
Maybe it's time to take a step back, put this on the roadmap, and actually prioritize the hard task of basing our tools on Ring? Or at least refuse accepting new contributions which further muddy the waters... Code Importer is a project with a clear goal: parsing/saving chunk formatter stuff. Its visitor may create ring objects that are displayed in an external browser (when you press code browse) or if you want to have them in chunk format for now. Or create MCMethodDefinition.
Ideally we would like to remove chunk format and codeImporter would go away. We would love