Home » Modeling » EMF » Working with generated code
|
| Re: Working with generated code [message #726031 is a reply to message #725989] |
Fri, 16 September 2011 12:46   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi,
Assuming your code is in git/svn or cvs, for your specific case:
- regenerate from the model (this should maintain the current manual changes)
- check any changes (there shouldn't really be any changes) against your code repository
- commit/push your changes
- delete all the generated code (including all the manual changes)
- regenerate the code (which now has no manual changes)
- do a diff against your code repository to get all the manual changes.
- rollback everything to the state stored in the code repository
You can install mint also which I think highlights changed sources.
For myself, I work directly with and change the generated code, the diff tools of code repositories give me enough
instruments to identify changes and also be able to rollback anything I accidentally removed.
gr. Martin
On 09/16/2011 01:08 PM, Adrian Mouat wrote:
> Hi,
>
> I'm wondering what everyone's techniques are for working with generated code. I've inherited a large GMF/EMF code-base
> and I'm really struggling to find a way to identify all the places where the code has been edited.
>
> At first I thought I could just search for "generated NOT", but this doesn't work as it doesn't pick up methods and
> classes that have been added without editing generated code.
>
> It seems the original developer started by keeping all his edits in a separate src-my folder, which included both new
> classes and edited generated classes. The developer moved away from this approach later, presumably as they got bored of
> deleting generated files and keeping changes to generated code in sync. This actually led to some modifications being
> lost as some modified methods didn't edit the @generated annotation and therefore were overwritten when moved back to
> the src folder.
>
> So, my questions are:
>
> - how should I identify edited code?
> - what is the best workflow for working with EMF code generation?
>
> Thanks,
>
> Adrian.
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: Working with generated code [message #726071 is a reply to message #726052] |
Fri, 16 September 2011 13:46 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Adrian,
Mint had a nice feature for all this. It effectively filters out
methods/fields marked @generated so you only saw what was hand written.
The merging generator works as follows. It generates the new source
in-memory and reads the old source also into memory. Then it matches
the structure of the two uses the names to establish a map. Anything in
the new source not matched to the old source is pushed in. Anything in
the old source that's marked @generated and matches new source, pulls in
the new source. Anything in the old source that's marked @generated and
matches no new source is swept. Push, pull, sweep. Imagine if you did
only the sweep. All you'd have left is the things hand written. It
would be nice, if I were made of time, to write such a utility.
More comments below.
On 16/09/2011 6:24 AM, Adrian Mouat wrote:
> Thanks Martin, that's a good suggestion, although quite heavy-weight.
Yes, but you have to clean up the mess someone else left behind to get a
handle on it.
>
> Unfortunately the code I inherited did change when I regenerated :(
Most of the templates don't change all that often...
> Although this may be the original developer's fault, I suspect it
> happens all to easily if you only regenerate infrequently.
Some minor changes, but not so much generally...
>
> One of the annoying issues I had was that the gmfgen files hadn't been
> checked in (as they are created from the gmfmap) and various changes
> were lost.
There source artifacts that definitely should be kept around.
> There doesn't seem to be a good way to track the changes to genmodel
> and gmfgen files except by writing them in a text file :(
There XML serialization can be tracked like any other text file and EMF
Compare is quite nice for showing the changes in a more structural way...
>
> One issue with your suggestion is that changing the version of the
> generator can also cause changes.
I can't comment on the GMF generator, but certainly the EMF generator
has not dramatically changed what it produces over the years.
> (To this end I would suggest that a comment should be added to all
> generated files with the version of the generator and the date of
> generation).
Not surprisingly, such options are already available in the generator.
Of course when you include the date of generation, your files will
always change.
>
> Another issue is that "dead" code (code that was generated but is no
> longer) looks like hand-edited code rather than just falling away :(
The worst case of this are unused imports that are easily removed with
Source->Organize Imports... If you rename classes completely, you do
need to keep track of garbage files...
>
> If there is any more advice I'd be happy to hear it - my code base is
> looking prety unmaintainable at the minute. Is anyone using EMF/GMF on
> a multi-developer team? Did you have to put special processes in place?
The Xtext guys use an approach where they keep the generated source
entirely separate; that works well, but doubles the number of
implementation classes. They specialize the generator to accomplish this.
I think there are not significant problems with the "normal" approach if
you occasionally regenerate (at least once per release) and look closely
at what's changing. The worst problem is deleting classes or renaming
them. That will take some effort to clean up. Better to use Java
refactoring to also refactor the things being renamed before
regenerating with the renamed model.
>
> Thanks,
>
> Adrian.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Working with generated code [message #726114 is a reply to message #726098] |
Fri, 16 September 2011 15:32 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
On 16/09/2011 7:51 AM, Adrian Mouat wrote:
<blockquote cite="mid:j4vn3j$3jr$1@news.eclipse.org" type="cite">Thanks
Ed.
<br>
<br>
Actually, I wasn't aware of the sweep stage, so that's good to
know.
<br>
<br>
The problem with diffing the genmodel and gmfgen files is that the
edits are normally done via the Eclipse editor, not directly in
the XML, so it is hard figure out from the diff output how the
changes should be made via the editor. </blockquote>
Certainly for the GenModel, most information is stored as attributes
so it's very easy to see what property and what textual change is
needed.<br>
<blockquote cite="mid:j4vn3j$3jr$1@news.eclipse.org" type="cite">Therefore
a text file describing the changes is actually quite handy.
<br>
</blockquote>
Soon there will be Xcore, and the GenModel information will be in
the form of @GenModel(key="value")<br>
<blockquote cite="mid:j4vn3j$3jr$1@news.eclipse.org" type="cite">
<br>
I have to say I prefer the approach of keeping generated code
completely separate.</blockquote>
It's a bit of a religion: <br>
<blockquote><a
href="http://ed-merks.blogspot.com/2008/10/hand-written-and-generated-code-never.html">http://ed-merks.blogspot.com/2008/10/hand-written-and-generated-code-never.html</a><br>
</blockquote>
Good tools (I'm not saying we have them) can make the two
effectively indistinguishable/equivalent.<br>
<blockquote cite="mid:j4vn3j$3jr$1@news.eclipse.org" type="cite">
The "normal" approach seems to hinge on the assumption that
regeneration is only rarely performed</blockquote>
No, definitely not.<br>
<blockquote cite="mid:j4vn3j$3jr$1@news.eclipse.org" type="cite">
which seems unnecessarily limiting to me. I think one of the
reasons I'm struggling to grips with EMF/GMF development is that I
didn't appreciate this assumption before.
<br>
</blockquote>
It's easy for people to make a mess. One good thing is, after
committing all your carefully crafted changes, run the generator
again. Make sure nothing changes. That deals nicely with "Oops, I
forgot to change it to @generated not". The generator is far more
stable than you seem to be assuming. <br>
<br>
Of course I work with models (many of them) that need to be
API/binary compatible, so problems like renaming or deleting a class
simply don't arise...<br>
<blockquote cite="mid:j4vn3j$3jr$1@news.eclipse.org" type="cite">
<br>
Thanks again for your help.
<br>
<br>
Adrian.
<br>
<br>
<br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 10:59:43 GMT 2024
Powered by FUDForum. Page generated in 0.03998 seconds |
] 
Search
Help
Register
Login
Home
