Community
Participate
Working Groups
Build Identifier: 20100218-1602 The JMerger ignores the 'sourceTransfer' when merging the super type. For example if one takes the original emf-merge.xml and modifies it to look like this: <merge:pull sourceGet="Type/getSuperclass" sourceTransfer="(\s*@\s*extends)(.*?)(?:<!--|(?:\n\r?|\r\n?))" targetMarkup="^lastgen$|^gen$|^modifiable$|^model$" targetPut="Type/setSuperclass"/> <merge:pull sourceGet="Type/getSuperInterfaces" sourceTransfer="(\s*@\s*implements)(.*?)(?:<!--|(?:\n\r?|\r\n?))" targetMarkup="^lastgen$|^gen$|^modifiable$|^model$" targetPut="Type/addSuperInterface"/> Then, one would expect to see that the super type is taken from the original code. For example if the existing code (or so called 'target') is like this: /** * Data class. * <!-- begin-user-doc --> * @extends DataContent * @implements Serializable * <!-- end-user-doc --> * @generated */ public class Data extends DataContent implements Serializable { .... } and the generated code (so called 'source') is like this: /** * Data class. * <!-- begin-user-doc --> * <!-- end-user-doc --> * @generated */ public class Data { .... } then I would expect to have the original preserved. Instead I get /** * Data class. * <!-- begin-user-doc --> * @extends DataContent * @implements Serializable * <!-- end-user-doc --> * @generated */ public class Data implements Serializable { .... } Where, the super type is gone besides the fact that existed in the target and the pull rule has specified a source transfer. The fault appear to be in the org.eclipse.emf.codegen.merge.java.JMerger.applyPullRules(JNode, JNode) method. In my copy of the source code this will be line 773 : targetPutMethod.invoke(targetNode, new Object [] { value }); where the oldValue is completely ignored. While this is intended implementation or not, I do not know. The newsgroup is down so I can discuss it there. Hence, the bug report. I only hope I am not creating too much useless noise. Regards - Stefan Reproducible: Always
No, it's only intended to deal with *adding* interfaces to the extends of an interface or to the implements of a class (they're used as synonyms and work in either context) not to override or replace what's being merged in from the source. You can mark the class with @generated not to take over both the class being extended and the interfaces being implemented. Merging within the body of the class will still work (only @generated NOT will block merging for the whole file). The special case you show of a class that extends nothing never happens in EMF's code generator, so you're using JMerge for your own code generator?
I see now. Then this is not a bug and can be closed. > The special case you show of a class that extends nothing never happens in EMF's code generator, so you're using JMerge for your own code generator? Yes, I use JET1 to generate the code using my own templates. Then I use JMerge to merge the result with the existing code.
It is working as designed and the use of @generated not seems not so bad, so I am tempted just to close it, yes...
Closed the bug since it works as expected.
The fix is available in the latest build for the stream.