Home » Modeling » EMF » team dev, git, and emf code gen
| team dev, git, and emf code gen [message #1798941] |
Tue, 27 November 2018 17:34  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Howdy,
There's a group that (for the moment) is using/stuck on the Luna version of Eclipse, EMF, and egit.
After several static years, they are now updating the ecore model and regenerating the associated java code...then using git to push the model, generated code and all associated resources. There are occasions where generated code is amended with hand-code.
They've been having some difficulties with merging work of multiple devs:
Dev 1 will add a new type to ecore -> gen code -> commit on branch -> attempt to merge to common target branch (e.g. master)
Dev 2 will do same thing...with different/other type (in same package)
Then when the second one tries to merge on common branch they get conflicts...in the .ecore, in common java classes (e.g. factories/impls, etc).
Two questions:
1) Does this seem like a bug/bugs (in Eclipse, git, and/or EMF) that have been fixed since Luna?
2) Is there a specific process...for EMF codegen and/or git...that's recommended for such cases?
3) Both?
Thanksinadvance,
Scott
[Updated on: Tue, 27 November 2018 17:40] Report message to a moderator |
|
|
| Re: team dev, git, and emf code gen [message #1798963 is a reply to message #1798941] |
Wed, 28 November 2018 06:05  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
It seems to me that the process you describe inherently leads to merge/rebase conflicts that must be resolved manually. Specifically consider that adding an EClass to the *.ecore adds some lines at the end of the EPackage's serialization. If two developers do this independently, they will each have added some lines at exactly the same line number in the *.ecore file. That will lead to conflict (in any file, regards of the purpose/type of that file) and must be resolved manually by ensuring that both sets of line are present in the merged *.ecore. Some of the generated classes will have exactly analogous problems, e.g., in the x.yz.XyzPackageImpl.createPackageContents() lines will be added at exactly the same file location in the Java file. No tools can merge/rebase these things automatically; changing the same lines in two different ways is just inherently conflicting, so it's not 1) a bug.
For 2), the specific process one out to follow is to manually merge the *.ecore file itself first. Then do the same with the *.genmodel which will have exactly the same type of problem; inserts at the same line location. The EMF Compare tool does structural comparison so that might be useful for doing the manual merging to ensure that the final result of each contains both additions and result in a structurally sound serialization; but textual merging should work fine for each because both *.ecore and *.genmodel use cross references that are resilient to reordering and the XML is simple. At that point, its not really so sensible or necessary to manually merge any generated Java code. Instead, open the *.genmodel which can and will correctly generate the merged Java results, and at this point you'll be sure the *.ecore and *.genmodel are structurally sound because they'll be loaded and validated. The results of merging the *.ecore and the *.genmodel along with the generated results of that is what should be committed to end up with a final consistent merged result.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: team dev, git, and emf code gen [message #1798968 is a reply to message #1798963] |
Wed, 28 November 2018 07:00 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
In practice, I find genuine *.genmodel conflicts are rare since the only important part is the GenModel/GenPackage configuration that rarely changes. Unless you are really exploiting the Edit configurations, all the GenClass/... content is 100% auto-generated, so once you sort out the *.ecore you can just reload. Or manually merge the GenModel/GenPackage and delete all the nested GenClass/... content and allow the tooling to regenerate it.
Ecore conflicts are generally very fine-grained and so best resolved manually. Either by choosing one development as master and re-implementing the other, possibly by DND although that doesn't always worth in the Sample Ecore Editor. If you allow GIT to give the conflicting merge, the result is illegal XML, but the merge markup is easily searched to guide you to the conflicts.
I therefore recommend use of your favourite text editor to fixup the conflicts at the XML level.
When maintaining GIT I recommend a triple commit.
a) the modified *.ecore (and perhaps *.genmodel) files - this contains the intellectual input
b) the regenerated Java files and optionally minimal manual cleanups such as imports - this contains autogenerated reaction and mindless changes
c) the modified support code that exploits the model changes - this contains further intellectual content
Then when you come to a difficult merge, you can merge the a)'s then regenerate, and clean to re-implement the b)'s, then merge the c)'s that contain 'real' code.
If you use '@Generated NOT' code you may choose to repeat the b) to discover how many '@generated NOT's have been accidentally omitted. Re-instate them so that your regeneration is not lossy.
Bottom line: XML editing with a text editor puts you in control. Fancier tooling gives you extra and more complex problems to navigate. And of course while doing the manual merge you have an opportunity to reflect on whether the merges really co-exist sensibly or deserve revision.
Regards
Ed Willink
|
|
|
| Re: team dev, git, and emf code gen [message #1798989 is a reply to message #1798968] |
Wed, 28 November 2018 11:06 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
Since you are moving from Luna, you may encounter trivial but awkward whitespace issues with simple text comparison. It may therefore be appropriate to perform a dummy *.ecore edit before comparison to ensure the same save options are in force. You might choose to use something like [1] to normalize your *.ecore into alphabetical order further reducing irrelevant differences. (When using Compare Views and GIT, make sure you close Compare Views, particularly EMF Compare Views, as soon as possible since GIT seems to cause them to recompute differences far too often, sometimes very slowly, and usually long after you have lost interest in them.)
Total merge as I suggested before may not be appropriate. If you are merging changes [A1...A10] with [B1...B4] you may decide that [B1...B4] is the most sound and so use that as the base for a 'redevelopment' of [A1...A10]. If you have extensive JUnit tests, a stepwise 'redevelopment' of A1, then A2 etc can be very beneficial and very time consuming. Beneficial because when it turns out that A4 and A8 have serious semantic conflicts, you can focus on fixing A4 then A8 in turn rather than everything at once. Time consuming since you get to debug 9 ultimately useless intermediate redevelopment steps.
If you have some name refactoring to contend with. Oh dear. Really painful. I've not found an easy way. Performing a Java refactoring on the EMF generated output, before you regenerate from Ecore can significantly reduce the pain.
Regards
Ed Willink
[1] https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/examples/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/utilities/EPackageAlphabetizer.java
|
|
|
Goto Forum:
Current Time: Sat Apr 20 02:04:15 GMT 2024
Powered by FUDForum. Page generated in 0.03648 seconds |
] 
Search
Help
Register
Login
Home
