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: [email protected] For additional commands, e-mail: [email protected]
