Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 356680 - Import of other Ecore models does not allow to reuse the imported declarations
Summary: Import of other Ecore models does not allow to reuse the imported declarations
Status: CLOSED WORKSFORME
Alias: None
Product: OCL
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: OCL Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-04 12:12 EDT by Michele Mancioppi CLA
Modified: 2013-05-20 11:37 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michele Mancioppi CLA 2011-09-04 12:12:36 EDT 
Build Identifier: 20110615-0604

I am using the 3.1.1.v20110830-1428 OCLinEcore build that should fix the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=353793.
While the build does fix the 353793 bug, it still does not solve all the problems with the imports. Declarations in imported packages are not "visible" in the ecore model that perform the import. Moreover, when saving, closing and re-opening the ecore models that use imports, the imported packages are replaced with the default ecore 'http://www.eclipse.org/emf/2002/Ecore#/', and the referenced types are replaced by ecore::EObject

Reproducible: Always

Steps to Reproduce:
1. Create two simple ecore models, A and B, and have B import A
2. Create a class in A, say AClass, and one in B, say BClass
3. Have BClass extend AClass
4. Save the B.ecore file and close the editor.
5. Reopen the editor: All the information on A.ecore is gone, and the references to types declared in A are replaced by ecore::EObject
Comment 1 Ed Willink CLA 2011-11-09 03:48:40 EST 
Sorry somehow I missed this one. I don't think it's critical; at most major since the problem is on the 'load' path.

Using Indigo SR1, I cannot reproduce the problem on an extends, but I can reproduce the type reference problem:

module _'A.ecore'
package a : aaa = 'platform:/resource/Activity/A.ecore'
{
	class A;
	class A2;
}
-----------------------------------------------------------------
module _'B.ecore'
import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';
import aaa : 'A.ecore#/';

package b : bbb = 'platform:/resource/Activity/B.ecore'
{
	class B extends aaa::A
	{
		property a2 : aaa::A2;
	}
}

reloads as

module _'B.ecore'
import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';
import aaa : 'A.ecore#/';

package b : bbb = 'platform:/resource/Activity/B.ecore'
{
	class B extends aaa::A
	{
		property a2 : ecore::EObject[1];
	}
}
Comment 2 Ed Willink CLA 2011-11-09 04:52:48 EST 
I cannot reproduce this again. It would seem that I got lucky/unlucky with the exact ordering of editorial errors and saves.

One possibility is that a save was performed while the source text contained errors, which either were not shown to the user or were not diagnosed so as to inhibit a save. There is certainly no inhibition on saving when errors are shown so deliberately corrupting a reference emulates the repro.

Bug 363273 raised for the save hazard.
Comment 3 Ed Willink CLA 2013-05-20 11:37:58 EDT 
CLOSED after a year in the RESOLVED state.