7

I work on an EMF project. One of the design decisions was not to touch the generated code and not to check it in. Instead, whenever something needs to be changed, a sub-class is created that contains the changes. The framework is flexible enough to deal with this. However, I experience some work overhead.

The design decision was made on the base of bad experiences with other code generation frameworks were re-generation let to problems.

Being new to the project I would like to challenge that design decision but would like to hear the general opinion first. I know that the EMF project team recommends the in-code changes. But what are your experiences? How well does EMF handle manual code changes in the generated code? Did you ever come to a point where you lost manual written code? Did the code ever get into a non-maintainable state?

Lii
  • 11,553
  • 8
  • 64
  • 88
Wizard of Kneup
  • 1,863
  • 1
  • 18
  • 35

2 Answers2

7

But what are your experiences?

I've implemented two separate projects, both of which involved models with 50 or more model classes, and in both cases the models evolved throughout the lifetime of the project; i.e. lots of model changes. In both cases, I modified the generated code to typically to implement computed attributes, validation and to customize the editors in various ways.

How well does EMF handle manual code changes in the generated code?

It works well. Occasionally the generator produces code that doesn't compile due to some model change, but the fixes are typically simple; e.g. deleting Java classes/interfaces, dead imports, etc.

Did you ever come to a point where you lost manual written code?

Only very occasionally. Once in a while you forget to remove the "generated" marker comment and your method gets clobbered when you regenerate the model.

(I suppose if it was a major concern you could modify the EMF generator to always backup the source tree before merging in changes.)

I guess that the most irritating thing was that the generated code had to be formatted. Unfortunately, the Eclipse code formatter is pretty crass, but if you manually reformat, your formatting changes get clobbered next time you regenerate. But that's just irritating ... not something that is worth jumping through hoops to avoid.

Did the code ever get into a non-maintainable state?

Nope. Not ever.

Reading consta_a's answer reminds me that I always checked my generated EMF classes into version control. That's the best way to avoid losing hand edits in the long term.

Update in 2018: the 2 EMF projects I was talking about happened before 2008. Things may have changed in the EMF world since then. I have not been keeping track.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

I confirm Stephen C answer: in our case we handle about 120 classes in our model, which means 120 interfaces + 120 implementation classes + countless edit classes and regeneration goes quite well (if only we could easily make the generated classes formatted as we want (^_^))

Tip: If you fear losing some hand crafted code, the best is to keep your code in a repository. Every time you do a change, you can easily compare with previous version and see what has changed.

consta_a
  • 31
  • 7