Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348844

Summary:	File Conflict dialogue misbehaviour in tutorial plug-in
Product:	[Modeling] Graphiti	Reporter:	Juergen Pasch <juergen.pasch>
Component:	Core	Assignee:	Tim Kaiser <tim.kaiser>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	michael.wenz
Version:	0.8.0	Flags:	michael.wenz: juno+
Target Milestone:	0.9.0
Hardware:	All
OS:	All
Whiteboard:	Juno M5 Theme_bugs

Description Juergen Pasch

2011-06-09 04:32:11 EDT

Reproducable: always.
Steps to reproduce:
1. Create two diagrams with the tutorial plug-in (diagram type "tutorial")
2. Create an EClass and copy it
3. Paste EClass shape in the other diagram
4. Establish drill-down from one EClass with Custom->Associate diagram
5. Ensure both editors are dirty (e.g. move shapes)
6. Save one editor and change to the other editor by clicking its tab
7. The "File Conflict" pop-up dialogue will appear

From user point of vies this is not acceptable and intrinsincly confusing, since he is working with two different diagrams and the business object of the EClass has not been changed.

Comment 1 Michael Wenz

2011-06-09 07:28:38 EDT

Behind the scenes:
1) The created EClass is stored in the resource of the diagram in which it is created
2) Copying & pasting the EClass only copies the shapes but references the same EClass object from both diagrams now
3) In the diagram the EClass was pasted to only a reference to the EClass in the other resource is stored and this other resource is loaded on demand by EMF
4) For this second resource that is loaded on demand the flag "modification tracking" is not enabled
5) Saving this diagram (the one the EClass was pasted to) after a pure diagram change saves both resources: the own diagram resource (there are changes, since the shape was moved) and also the other diagram resource in which in fact nothing changed, since it is loaded without modification tracking set
6) Activating the other diagram notifies the user of the external change to the diagram resource

So technically fully understandable but hard to grasp for users.

2 things to consider:
- Try to set modification tracking for all resources. This will in the above scenario prevent the save on the second diagram resource (step 5)
- Consider seperating diagram and domain data resources for the tutorial right from the beginning. (This will not actually solve the above issue, but will help in making such scenarios easier to understand. BTW, this is also the recommended way to build tools using Graphiti.)

Michael

Comment 2 Michael Wenz

2011-07-19 04:11:54 EDT

Would like to target for Juno

Comment 3 Tim Kaiser

2011-12-01 09:27:46 EST

the bug is fixed in the bug336488 branch. 
we supply the save_only_if_changed option to the resource save.

Comment 4 Michael Wenz

2011-12-08 10:45:03 EST

Will not become part of juno M4 because it is part of the larger editor API changes. Will be integrated in head in the early M5 timeframe

Comment 5 Michael Wenz

2011-12-21 10:52:09 EST

Has been integrated back into master and pushed to Eclipse. Retest was done

Comment 6 Michael Wenz

2012-02-17 04:22:19 EST

*** Bug 371730 has been marked as a duplicate of this bug. ***

Comment 7 Michael Wenz

2012-04-11 10:51:42 EDT

Bookkeeping: Set target release

Comment 8 Michael Wenz

2012-06-29 04:18:16 EDT

Part of Graphiti 0.9.0 (Eclipse Juno)