|Need help on JET + JMerge custom code regeneration [message #59913]
||Fri, 24 April 2009 08:22
| Francis Gavino
Registered: July 2009
I tried to follow the example in the developerWorks article
http://www.ibm.com/developerworks/library/os-ecemf3/, specifically the
"Fine-grained customizations" part where I have a rule that will allow
some custom code inside code markers (and the rest is regenerated from the
template). I can't seem to make it work - the custom code inside the
markers are retained but the custom code outside the markers are also
retained after regeneration. Has there been changes to this feature of JET
or JMerge since the writing of this article that could affect this? I'm
using Rational Software Modeler version 7.5.1. Any help will be
|Re: Need help on JET + JMerge custom code regeneration [message #60275 is a reply to message #59913]
||Thu, 30 April 2009 12:02
| Paul Elder
Registered: July 2009
You might try asking this on the EMF newsgroup. JET simply reuses EMFs
But, I happen to have done such things several years ago. Here's what I
1) it was messy
2) JMerge works by first traversing the AST of each class, and applying
patterns (as in java.util.regex.Pattern) to aspects of the elements. Each
pattern must define a 'capture' which is used as a markup. Here a few
examples from EMF's jmerge rules:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.codegen.ecore/templates /emf-merge.xml?revision=1.12&root=Modeling_Project&v iew=markup
The first pattern looks for an @ followed by whitespace followed by
'model' on the comment of any Member of the class. The capture the match
is 'model', so anything that matches this pattern will have an JMerge
annotation 'model' on it.
The second pattern is uglier, but its matching @generated, and giving
elements with that match a 'gen' markup.
3) Once AST elements are marked up, JMerge goes through it three times (I
may have the order of the first two wrong):
i) 'push' elements in the generated source but not in the existing source
into the final result. You don't get to write rules about this. I just
ii) 'pull' elements existing in both the generated source and the existing
source. Here you need 'merge:pull' rules in your JMerge file. Here's the
rule that copies method bodies of methods that have a 'gen' markup:
The targetMarkup attribute is a pattern that matches markups on the AST
elements. Note the ^ and & anchors, which ensure the pattern is not
matching only a portion of the markup.
Also note that, you need a pull rule for each attribute you want copied.
So, methods need ones for the return type, the method body, the java doc...
iii) 'sweep' elements from the existing file that do not exist in the
generated file. This is driven by 'merge:sweep' rules, again, working on
So... to do what you want, you need to:
1) identify methods with a merge:patternDictionary that have your special
'user code' markup in it. You have to include a 'capture' in that rule
that you can then use in your 'merge:pull' targetMarkup attributes.
2) copy the method bodies (using a sourceTransfer pattern in the pull
The problems start if a single AST element ends up with more than one
markup that then kicks of multiple pull rules for the same attribute. For
example, if an method has @generated in the javadoc (getting a 'gen'
markup, if you use the standard EMF rule) and your custom markup. In that
case, both pull rules will execute on your method, and leave you with an
So... this means that your markups should be disjoint - now two markups
should apply simultaneously to a single element if those markups trigger
pull rules on the same attribute. This is where my experience got messy. I
had to write quite complex patterns in both the patternDictionary and pull
elements in order to achieve it.
Hope this helps,
Powered by FUDForum
. Page generated in 0.01720 seconds