Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » JMerge experiences
JMerge experiences [message #46548] Thu, 29 May 2008 10:12 Go to next message
Timothy Marc is currently offline Timothy Marc
Messages: 547
Registered: July 2009
Senior Member
Hello Transformers,

I read some input about JMerge, i think this is a simple but effective
approach for merging Java code.
Just one beginner question: The operations of JMerge operates an written
Java code both of source and target. Is this correct? In combination with
JET, one had to generate the String from JET first and then apply the merge
rules to both source code and target code.

Thanks for a short reply and confirmation.

Timothy
Re: JMerge experiences [message #46601 is a reply to message #46548] Thu, 29 May 2008 17:12 Go to previous messageGo to next message
Paul Elder is currently offline Paul Elder
Messages: 849
Registered: July 2009
Senior Member
Timothy:

JET2 has a <java:merge/> tag. Just put it in your Java templates (after any
<java:importsLocation/> tags, there is an undesirable interaction
otherwise).

The <java:merge/> tag does is the following:
1) During template execution, it does nothing at all (except set a flag
indicating that a JMerge is required).
2) As the JET engine finalizes the generated output, the tag kicks in and
checks for an existing version of the class. If found, a JMerge is run and
the result is written. If there is no existing class is found, then the
original buffer contents are written.

As for an opinion on JMerge, I have two views:
1) I like it - it has a simple usage contract that users can understand.
2) Your transformation will be better if you can avoid merges entirely. In
many cases (at least with Java code), you can do this by refactoring your
generated code into two kinds of classes: i) those that are 100% generated;
and ii) those that are 100% under user control. As a convenience to the
user, the transformation may create files in ii), but it would never modify
them. Physically separating the two kinds of files into different folders
makes this even easier for the user.

Paul
Re: JMerge experiences [message #46739 is a reply to message #46601] Sun, 01 June 2008 10:03 Go to previous messageGo to next message
Timothy Marc is currently offline Timothy Marc
Messages: 547
Registered: July 2009
Senior Member
Dear Paul,

thank you, i've know get use of JMErge with JET1. It works fantastic.

Timothy

Paul Elder schrieb:
> Timothy:
>
> JET2 has a <java:merge/> tag. Just put it in your Java templates (after any
> <java:importsLocation/> tags, there is an undesirable interaction
> otherwise).
>
> The <java:merge/> tag does is the following:
> 1) During template execution, it does nothing at all (except set a flag
> indicating that a JMerge is required).
> 2) As the JET engine finalizes the generated output, the tag kicks in and
> checks for an existing version of the class. If found, a JMerge is run and
> the result is written. If there is no existing class is found, then the
> original buffer contents are written.
>
> As for an opinion on JMerge, I have two views:
> 1) I like it - it has a simple usage contract that users can understand.
> 2) Your transformation will be better if you can avoid merges entirely. In
> many cases (at least with Java code), you can do this by refactoring your
> generated code into two kinds of classes: i) those that are 100% generated;
> and ii) those that are 100% under user control. As a convenience to the
> user, the transformation may create files in ii), but it would never modify
> them. Physically separating the two kinds of files into different folders
> makes this even easier for the user.
>
> Paul
>
>
Re: JMerge experiences [message #46758 is a reply to message #46601] Sun, 01 June 2008 10:27 Go to previous messageGo to next message
Timothy Marc is currently offline Timothy Marc
Messages: 547
Registered: July 2009
Senior Member
Hi,

it's me again.
Just a question concerning the documentation of JMerge. I've searched in
the web and the help files, but there is no document, which describes
the available elements in a rule and their attributes.
Is there somewhere outthere an API nly for the configuration of the rules?

Timothy

Paul Elder schrieb:
> Timothy:
>
> JET2 has a <java:merge/> tag. Just put it in your Java templates (after any
> <java:importsLocation/> tags, there is an undesirable interaction
> otherwise).
>
> The <java:merge/> tag does is the following:
> 1) During template execution, it does nothing at all (except set a flag
> indicating that a JMerge is required).
> 2) As the JET engine finalizes the generated output, the tag kicks in and
> checks for an existing version of the class. If found, a JMerge is run and
> the result is written. If there is no existing class is found, then the
> original buffer contents are written.
>
> As for an opinion on JMerge, I have two views:
> 1) I like it - it has a simple usage contract that users can understand.
> 2) Your transformation will be better if you can avoid merges entirely. In
> many cases (at least with Java code), you can do this by refactoring your
> generated code into two kinds of classes: i) those that are 100% generated;
> and ii) those that are 100% under user control. As a convenience to the
> user, the transformation may create files in ii), but it would never modify
> them. Physically separating the two kinds of files into different folders
> makes this even easier for the user.
>
> Paul
>
>
Re: JMerge experiences [message #46840 is a reply to message #46758] Tue, 03 June 2008 19:05 Go to previous messageGo to next message
Paul Elder is currently offline Paul Elder
Messages: 849
Registered: July 2009
Senior Member
Timothy:

Best link I could find was an IBM developerWorks article.

http://www.ibm.com/developerworks/opensource/library/os-ecem f3/

But, I must confess that most of what I've learned on JMerge was learned
by reading the code:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf/plugins/org.eclipse.emf.codegen/src/org/eclipse /emf/codegen/merge/java/facade/ast/?root=Modeling_Project

The rules file used by EMF is here:

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

If you look at a rule in this file (such as this one):

<merge:pull
sourceMarkup="^modifiable$"
sourceGet="Member/getComment"

sourceTransfer="(\s*&lt;!--\s*begin-user-doc.*?end-user-doc\s*-- >\s*)(?:\n\r?|\r\n?)"
targetMarkup="^modifiable$"
targetPut="Member/setComment"/>

You see things like Member/getComment. These are references to
types/methods i n the JDOM API. JMerge has since moved onto the JDT AST,
but it still maintains those references.

I don't have time to dump all I know right now, but hopefully this is a
start.

Paul
Re: JMerge experiences [message #60373 is a reply to message #46758] Fri, 01 May 2009 17:01 Go to previous message
Paul Elder is currently offline Paul Elder
Messages: 849
Registered: July 2009
Senior Member
Timothy:

You are right, there is no documentation. Everything I learned came from
reading the code :-(.

But, a good starting point (if you don't want to read the code) is to
take a look at this package:

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/references/javadoc/org/eclipse/emf/codegen/merge/j ava/facade/package-summary.html

All the J classes correspond the first step in the 'select' attributes
(without the J). The public member get/set functions correspond to the
second step. So select="Member/getComment" is a reference to
JMember.getComment().

Paul
Previous Topic:Need help on JET + JMerge custom code regeneration
Next Topic:Getting children of a supertype element
Goto Forum:
  


Current Time: Sat Sep 20 02:08:10 GMT 2014

Powered by FUDForum. Page generated in 0.01830 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software