Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » XPand - JMerge Protected Region
XPand - JMerge Protected Region [message #884805] Mon, 11 June 2012 17:39 Go to next message
Karan Anand is currently offline Karan Anand
Messages: 8
Registered: June 2012
Junior Member
Hello!

We use xpand to generate JAVA files, and run JMerge post processor on the generated files. Things got interesting while trying to add support for protected regions.

We added a pull rule (in emf-merge.xml) to copy the protected region from existing to the emitted file. Everything works as long as the protected region is present in both the existing and emitted file. However, if a method is modified, and even with the '@generated' annotation intact, the JMerge post processor no longer overwrites the method.

Similar behavior has been reported before:

[link=http: //www.eclipse.org/forums/index.php/m/423892/]

[link=http: //www.eclipse.org/forums/index.php/m/60275/]

Basically, what we are trying to achieve is the following:
- Users should be able to add custom-code blocks wherever they want (i.e. custom code blocks exist only in existing files, and not in the generated files)
- Code in such blocks is retained across generations, but the rest of the code is cleaned up and overwritten by the generated code.

But we could not figure out a clean solution for this, without modifying the org.eclipse.emf.codegen.merge.java.JMerger class.

Can somebody please confirm whether this is possible at all? If yes, how?

We came up with an approach to have custom code blocks at the beginning and at the end of the methods. But with this, any changes to methods that do not need to retain modifications, are not overwritten.
Are there any alternate approaches we should consider?

Thanks a lot in advance.

Best,
Karan Anand

P.S. version #s
org.eclipse.emf.codegen 2.6.0
org.eclipse.gmf.xpand 2.1.0

Re: XPand - JMerge Protected Region [message #884930 is a reply to message #884805] Tue, 12 June 2012 01:49 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25946
Registered: July 2009
Senior Member
Karan,

Comments below.

On 11/06/2012 11:39 PM, Karan Anand wrote:
> Hello!
>
> We use xpand to generate JAVA files, and run JMerge post processor on
> the generated files. Things got interesting while trying to add
> support for protected regions.
>
> We added a pull rule (in emf-merge.xml) to copy the protected region
> from existing to the emitted file. Everything works as long as the
> protected region is present in both the existing and emitted file.
> However, if a method is modified,
Modified in what way? An example will be helpful.
> and even with the '@generated' annotation intact, the JMerge post
> processor no longer overwrites the method.
>
> Similar behavior has been reported before:
>
> [link=http: //www.eclipse.org/forums/index.php/m/423892/]
>
> [link=http: //www.eclipse.org/forums/index.php/m/60275/]
>
> Basically, what we are trying to achieve is the following:
> - Users should be able to add custom-code blocks wherever they want
> (i.e. custom code blocks exist only in existing files, and not in the
> generated files)
> - Code in such blocks is retained across generations, but the rest of
> the code is cleaned up and overwritten by the generated code.
How does that look?
>
> But we could not figure out a clean solution for this, without
> modifying the org.eclipse.emf.codegen.merge.java.JMerger class.
>
> Can somebody please confirm whether this is possible at all? If yes, how?
> We came up with an approach to have custom code blocks at the
> beginning and at the end of the methods. But with this, any changes to
> methods that do not need to retain modifications, are not overwritten.
It would certainly be easier to use the "standard" pattern we use with
EMF. I.e., put things that are likely to need attention into separate
methods. In fact, the pattern you describe can easily be handled using
the "Gen" pattern. I.e., if you have a method

/**
* @generated
*/
void foo()
{
// generated stuff
}

you can write

/**
* @generated
*/
void fooGen()
{
// generated stuff
}

void foo()
{
fooGen();
}

And then in foo() you can write logic that precedes or follows a method
(much like you'd subclass and override a method as well as call super).

> Are there any alternate approaches we should consider?
>
> Thanks a lot in advance.
>
> Best,
> Karan Anand
>
> P.S. version #s org.eclipse.emf.codegen 2.6.0
> org.eclipse.gmf.xpand 2.1.0
>
>
Re: XPand - JMerge Protected Region [message #885143 is a reply to message #884930] Tue, 12 June 2012 10:25 Go to previous messageGo to next message
Karan Anand is currently offline Karan Anand
Messages: 8
Registered: June 2012
Junior Member
Hi Ed,

Thanks for your reply. I should have included an example, sorry for that.

Any way, here it goes:

For instance, consider the following emitted file :
/*
* @generated
*/
public void foo() {
... some generated code
// begin-user-code

// end-user-code
}
/*
* @generated
*/
public void bar() {
// Generated code
}


And here is an example of the existing file:
/*
* @generated
*/
public void foo() {
... some generated code
// begin-user-code
... user adds custom code
// end-user-code
}
/*
* @generated
*/
public void bar() {
// Generated code
... user modifies the method, but doesn't deface the annotation
}


After the JMerge processes the files, the final file looks something like this:

/*
* @generated
*/
public void foo() {
... some generated code
// begin-user-code
... user's custom code is retained
// end-user-code
}
/*
* @generated
*/
public void bar() {
// Generated code
... user's modified code is retained as well
}


In the method 'bar()' above, since the annotation wasn't defaced, the code should have been replaced by the generated code, but it wasn't.

Is this behavior expected? I found some other posts referring to a similar behavior.
I guess we can consider the approach you suggested, however I am trying to get my head around what is possible and what isn't.

Please let me know if I missed something or if anything is unclear.

Thanks again.

Best,
Karan
Re: XPand - JMerge Protected Region [message #885259 is a reply to message #885143] Tue, 12 June 2012 13:30 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25946
Registered: July 2009
Senior Member
Karan,

Comments below.

On 12/06/2012 4:25 PM, Karan Anand wrote:
> Hi Ed,
>
> Thanks for your reply. I should have included an example, sorry for that.
>
> Any way, here it goes:
>
> For instance, consider the following emitted file :
> /*
I notice you're using /* and not /**
> * @generated
> */
> public void foo() {
> ... some generated code
> // begin-user-code
>
> // end-user-code
> }
> /*
> * @generated
> */
> public void bar() {
> // Generated code
> }
>
> And here is an example of the existing file:
> /*
> * @generated
> */
> public void foo() {
> ... some generated code
> // begin-user-code
> ... user adds custom code // end-user-code
> }
> /*
> * @generated
> */
> public void bar() {
> // Generated code
> ... user modifies the method, but doesn't deface the annotation
> }
>
> After the JMerge processes the files, the final file looks something
> like this:
>
> /*
> * @generated
> */
> public void foo() {
> ... some generated code
> // begin-user-code
Did you write some rule for this? Generally we're only looking for
patterns like this in the comments...
> ... user's custom code is retained
> // end-user-code
> }
> /*
> * @generated
> */
> public void bar() {
> // Generated code
> ... user's modified code is retained as well
> }
>
> In the method 'bar()' above, since the annotation wasn't defaced, the
> code should have been replaced by the generated code, but it wasn't.
Yes, depending on your rules. Are you starting with the emf-merge.xml
we're using for EMF's code generator?
> Is this behavior expected? I found some other posts referring to a
> similar behavior.
> I guess we can consider the approach you suggested, however I am
> trying to get my head around what is possible and what isn't.
>
> Please let me know if I missed something or if anything is unclear.
I'm wondering what rules you're using.
>
> Thanks again.
>
> Best,
> Karan
Re: XPand - JMerge Protected Region [message #885264 is a reply to message #885259] Tue, 12 June 2012 13:47 Go to previous messageGo to next message
Karan Anand is currently offline Karan Anand
Messages: 8
Registered: June 2012
Junior Member
Hi Ed,

'/*' is a typo, I typed all the code in the example by hand, in the generated classes, we do use '/**'.

Yes, we do start from emf-merge.xml, and the only change is modification of the method's body rule.

<merge:pull
sourceGet="Method/getBody"
targetMarkup="^gen$"
sourceTransfer="(\s*//\s*begin-user-code.*?//\s*end-user-code\s*)\n"
targetPut="Method/setBody"/>

This is based on the following tutorial:

www.ibm.com/developerworks/library/os-ecemf3/

Should the code in the 'bar()' method be retained? I mean, based on the rule, only the user-code block between the 2 lines of comments should be preserved. Is my understanding correct?

Thanks,
Karan
Re: XPand - JMerge Protected Region [message #885399 is a reply to message #885264] Tue, 12 June 2012 19:23 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25946
Registered: July 2009
Senior Member
Karan,

Comments below.

On 12/06/2012 7:47 PM, Karan Anand wrote:
> Hi Ed,
>
> '/*' is a typo, I typed all the code in the example by hand, in the
> generated classes, we do use '/**'.
>
> Yes, we do start from emf-merge.xml, and the only change is
> modification of the method's body rule.
>
> <merge:pull
> sourceGet="Method/getBody"
> targetMarkup="^gen$"
> sourceTransfer="(\s*//\s*begin-user-code.*?//\s*end-user-code\s*)\n"
This pattern needs to match in both the source and the target, otherwise
the rule won't be applied at all.
> targetPut="Method/setBody"/>
>
> This is based on the following tutorial:
>
> www.ibm.com/developerworks/library/os-ecemf3/
>
> Should the code in the 'bar()' method be retained? I mean, based on
> the rule, only the user-code block between the 2 lines of comments
> should be preserved. Is my understanding correct?
>
> Thanks,
> Karan
Previous Topic:[Xcore] Problems using opposite
Next Topic:EMF Transaction find deleted elements
Goto Forum:
  


Current Time: Wed Jul 30 23:27:25 EDT 2014

Powered by FUDForum. Page generated in 0.01661 seconds