Community
Participate
Working Groups
When a java compilation unit is generated for the first time, all imports are organized in it. However, when it is regenerated again (even if no changes have been introduced into the model or templates), all type references become fully qualified (and all imports are marked as redundant). All fully-qualified type names that are also defined using import statements should be replaced with short names prior to import reorganizing.
I am sorry, I am still unable to reproduce the case. I will be trying further. However, there is also some small possibility that this problem could become fixed with the help of Artem Tikhomirov's changes, made on February, 7 to org.eclipse.gmf.internal.common.codegen.GeneratorBase. They are already available in the latest gmf night build N20070208. But I know of some imports postprocessor issue if _template_ produces references for qualified and unqualified same-named types at the same time. In this case postprocessor assumes unqualified ones as references for types in the same package, and thus leaves the other ones fully qualified, unlike the previous ImportAssistant mechanism, which imported qualified names in such cases, so it is hard to track them. I hope new behavior is the expected one.
While investigating the steps to reproduce, I have found out the cause of the problem. It does not seem related to the import rewriter any more. After the recent changes in the GeneratorBase, sometimes, the old contents of the compilation unit are cached on line 324 (hereinafter called "oldest state"), then the file is modified on line 328 ("intermediate state"), and finally the (presumably correct, "new state") contents of the formatted output with the imports organized is compared to the oldest state (note that the file on disk corresponds to the intermediate state). If they match, the new output is ignored on line 340. Thus, the file on disk represents the intermediate state, whereas the reason for not saving it is that is is expected to be in the oldest state. This behavior is only observed if the compilation unit is not opened in the editor. If it is, the contents are ignored without saving, but the editor still displays the new state. (This is probably why it was not so easy to reproduce the problem).
Increasing severity to major, because, for the reasons given above, if the original code contained @generated NOT blocks, they are in fact replaced with the generated code.
Created attachment 58667 [details] To avoid unsafe file saving during adding manual imports it was delegated to the postprocessor itself.
reviewed and committed
[target cleanup] 2.0 M5 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Generation was the original product and component for this bug
