IMO it would be better to put the generated files e.g. *.generated.esv under a separate folder , e.g. src-gen
Most other MDSD tools and textual modeling tools for eclipse follow this pattern.

I think it has multiple advantages keeping generated and handwritten files in separate folders, it is a best practice.
e.g. deleting, make clean, version control etc…

Submitted by Bernhard Merkle on 11 June 2010 at 14:01

This is definitely something to consider. If we introduce this change then we have to make sure existing projects that have been using editor/*.generated.esv still work (which shouldn’t be that hard).

Note that these files are currently marked already as “derived” resources in Eclipse. This means that you get a warning when trying to edit them, and they are not checked into Eclipse-based version control unless you unmark them as derived. So it may be a mostly an aesthetic/convenience change. Introducing a new folder would also introduce some further clutter to the project structure (some have said we already have too many, and they have a point). Maybe the files are easier to find where they are now?

Hi Lennart,

yes marking them as derived etc saves some trouble and it is not really a problem.
however my aim would be to avoid as much codegeneration as possible.

the question is: why do you generate the *generated.esv at all ?
If they do not contain any meta-modell/language specific stuff they should not be generated and would better be put into the framework and into some spoofax/imp jar.

e.g. *-Colorer.generated.esv does not contain any language specific information.
hence I would put those defaults into the framework jar and reuse them from there.

the only one who seem to contain language specific information are (for the example) the
Folding and Outliner files.

As the project structure currently looks i would tend to have one toplevel src_gen folder and then under that have the structure with editor/trans/syntax/build etc.

You’re right that most of those generated files are not language-dependent at this point. However, by using this project structure we can always change that in the future: the lib/editor-common.generated.str file, for example, has a specialized parse-yourlang-file and pp-yourlang-file function in recent versions. Likewise, some of the other files may be specialized for the subject language in the future. We also use those files to minimize any surprises in the behavior of the editor: they ensure transparency of the editor definition. And as they can be regenerated with new versions of the plugin, they have an up-to-date comments section documenting any new features. So I would prefer to keep those files as .generated files, or, possibly, in a src-gen folder, instead of in some jar file.