Community
Participate
Working Groups
There is no code merging for generated plugin.xml for diagram plugin. If I change some values (for example: org.eclipse.ui.newWizards, %model_name% Diagram (wizard) - category, icon and name) next time I regenerate the diagram the value are re-set with default values and my changes are not kept.
This also applies to generated MANIFEST.MF files.
To my best knowledge, EMF doesn't merge plugin.xml as well. GMF doesn't introduce any additional support for merge. For manifest.mf we could try to use org.eclipse.emf.codegen.merge.properties.PropertyMerger (as EMF does)
It works in EMF. At least the following work: -when I change the Cathegory for the org.eclipse.ui.newWizards - the cathegory was kept after the re-generation of EMF (and it was not kept after re-generation of GMF) - when I add new extension points to plugin.xml with their properties they were kept after re-generation of EMF, while after re-generation of GMF all my changes were lost
It's not merging, it's simply "don't overwrite file if exists" approach. While it is reasonable (to certain extent) in EMF, it's not that simple with GMF - number of extensions EMF generates is far less than that of GMF. Thus, if GMF follows "don't overwrite" strategy, it's much easier to get into trouble (e.g. with wrong/obsolete extension being registered. New extensions would need manual efforts as well). If you feel the approach "don't touch existing file" is reasonable in GMF, let me know. It's quite easy to implement :)
sorry, it's my fault that use 'code merging' which is wrong term "If you feel the approach "don't touch existing file" is reasonable in GMF, let me know. It's quite easy to implement :)" Yes, I think it's very important, at least it's very important for me :)
*** Bug 146774 has been marked as a duplicate of this bug. ***
I don't think choosing either strategy (todays "overwrite" or "never overwrite" alternative) is good, but we ran out of time to provide an option to choose between them, gonna address this shortly after 1.0. In most cases there's some source code repository in use that keeps previous version of the file and makes possible to merge changes made in plugin.xml by hands.
How about generating two files, like plugin.xml and plugin.xml.bak for instance? My current mode of development when generating a diagram plugin is 1. make a copy of plugin project 2. generate plugin 3. compare and merge manually Sometimes (after I installed a new version of GMF tools) even: 1. make a copy of plugin project 2. generate plugin 3. make a different copy of generated plugin 4. delete plugin 5. generate plugin (to check if customized code has to be adapted a well) 6. compare and merge all three versions manually It would be great if GMF could do (1.) for me and backup those files which are going to be changed.
To Michael Haeberlen: if you keep your code in CVS then there is no need to make backup copies )))
I've added protected region support for plugin.xml so you could add extensions and they will be preserved on regeneration but the problem remains if you modify generated extensions ((( I could propose to add boolean property to gmfgen model to disable plugin.xml regeneration but it will be even more painful (((
(In reply to comment #9) > To Michael Haeberlen: if you keep your code in CVS then there is no need to > make backup copies ))) > Actually I do use CVS. The reason why I keep making copies is due to the (in my opinion) sub-optimal compare view of eclipse (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=128327). Using Beyond Compare to make a diff between folders is much more convenient for me. I admit that this has nothing to do with GMF.
Created attachment 53739 [details] Proposed merging code XML merging code using processing instructions to denote generated extension points
reviewed, refactored and committed
Did this fix address the similar problems in MANIFEST.MF files (e.g., as reported in duplicate bug 146774)? I have added dependencies to my MANIFEST.MF (Require-Bundle) that I would like to be preserved on re-generation. I can re-open bug 146774 and add my request there if this bug was not supposed to address the MANIFEST.MF file.
Created attachment 55249 [details] test and patch
Comment on attachment 53739 [details] Proposed merging code Next patch, https://bugs.eclipse.org/bugs/attachment.cgi?id=55249&action=edit, obsoletes this one
(In reply to comment #14) > Did this fix address the similar problems in MANIFEST.MF files (e.g., as > reported in duplicate bug 146774)? No, the fix is for plugin.xml only, and doesn't solve issues with manifest.mf Guess, bug 146774 is the right place to focus on manifest.mf
[target cleanup] 2.0 M3 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
