Added a "merge" mode to the Torque generator

[Thomas Fox <Th...@seitenbau.net>]

At $work, I use the torque code generator not only for generating torque
classes but also as a general code-generating tool. When doing so, I
sometimes have the problem that the generated code does nearly what it
should but it has to be tweaked at some places. In other words, the problem
is how generated code can be combined with small hand-written changes.
These changes should also survive a new generation run (e.g. after the code
is changed, you notice a problem elsewhere and fix it in the generation)
For the Torque templates, our solution is to create user modifiable classes
which inherit from generated classes. In my opinion, this is a good
solution for service classes (e.g. Peers). It is also ok for data container
classes in the Torque case because all generated fields must be there in
order for the code to work. But e.g. in general data container classes one
might want to remove fields, which is not feasible by the inheritance
approach (ok, one can make getters and setters throw an unchecked exception
but this is not pretty, isn't it ?). And it is totally clear that the
subclassing approach does not work for generating HTML code.....
So in some situations it is useful to have another method of combining
generated and hand-written code. My idea was the following:
- The user can edit the generated files
- The generator keeps a copy of the files generated in the last generation
run.
- On a new generation run, the generator compares 1) the newly generated
file to the last generated file and 2) the edited file to the last
generated file. It then does a three-way-merge on the results (this is what
e.g. subversion does when you have conflicts).

We have tried the approach at $work and it seems quite promising. There are
a few things to remember, though:
- Of course there can be conflicts (same line changed in the new generation
and manually). The conflicts will appear as <<<generated...---...edited>>>
sections in the generation result. In java code, this will be a compile
error, so these places are easy to spot.
- if the code generation is used by several persons, it eases the team
workflow (in our experience) if the unmodified generated sources are also
checked into version control. This ensures everybody has the same merge
basis.

I have checked the code in under the TORQUE-169 issue. If you are
interested, please give it a try. If you object to adding this feature,
please do so on this mailing list.
While doing this, I generalized the "what should we do if the generated
file already exists" configuration so other "what should the generator do
if the generated file already exists" strategies can be added easily.

One more thing - I used the jgit library (http://eclipse.org/jgit/) for
merging. It comes under the edl license (a bsd-style license,
http://www.eclipse.org/org/documents/edl-v10.php). It seems ok for me to
include it but I will check with legal if no-one objects.

     Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org