Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 354336 - [oclinecore] OCLinEcore Editor cannot load ecore file
Summary: [oclinecore] OCLinEcore Editor cannot load ecore file
Status: CLOSED FIXED
Alias: None
Product: OCL
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: M1   Edit
Assignee: OCL Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-10 03:49 EDT by Hauke Fuhrmann CLA
Modified: 2013-05-20 11:38 EDT (History)
1 user (show)

See Also:


Attachments
ecore file that cannot be opened with OCLinEcore editor (6.16 KB, application/xml)
2011-08-10 03:52 EDT, Hauke Fuhrmann CLA
no flags Details
StackTrace of OCLinEcoreEditor (6.41 KB, text/plain)
2011-08-10 03:54 EDT, Hauke Fuhrmann CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hauke Fuhrmann CLA 2011-08-10 03:49:53 EDT
Build Identifier: 20110615-0604

The attached ecore file cannot be opened in the OCLinEcore editor. Stack Trace attached. Additionally, it cannot be properly used in the CompleteOCLEditor as an import; types from the files cannot be found.

However, the ecore file can be opened correctly in the Sample Ecore Model Editor (Tree Editor), validates correctly and code generation works fine.

So what's wrong with the file?
Other files work fine.

Reproducible: Always

Steps to Reproduce:
1. Import the foo.ecore in a project
2. Open in OCLinEcoreEditor
Comment 1 Hauke Fuhrmann CLA 2011-08-10 03:52:32 EDT
Created attachment 201210 [details]
ecore file that cannot be opened with OCLinEcore editor
Comment 2 Hauke Fuhrmann CLA 2011-08-10 03:54:06 EDT
Created attachment 201211 [details]
StackTrace of OCLinEcoreEditor
Comment 3 Ed Willink CLA 2011-08-10 04:55:37 EDT
Thanks for a good repro. [It's usually worth pasting stack traces inline so that Bugzilla searches for duplicates see the offending class names.]

Problem is that foo::Bar1.start has an EAnnotation with a null source.

Should be a simple fix.
Comment 4 Hauke Fuhrmann CLA 2011-08-10 07:41:56 EDT
Ok, that helped, thanks.
Comment 5 Ed Willink CLA 2011-08-10 14:02:13 EDT
Once the unnamed EAnnotation is fixed, a problem arises with the references

      <eAnnotations references="http://www.eclipse.org/emf/2002/Ecore#//ELong/%http:%2F%2F%2Forg%2Feclipse%2Femf%2Fecore%2Futil%2FExtendedMetaData%"/>

which is a deeply suspect serialization that of course results in an unresolved proxy. This is silently ignored.

Better to ignore than blow up, but it would be good to announce the bad proxies in some popup.
Comment 6 Ed Willink CLA 2011-08-12 11:19:49 EDT
(In reply to comment #5)
> references="http://www.eclipse.org/emf/2002/Ecore#//ELong/%http:%2F%2F%2Forg%2Feclipse%2Femf%2Fecore%2Futil%2FExtendedMetaData%"/>
> 
> which is a deeply suspect serialization 

No it's fine; just looks wierd.

---------------

Annotations may now be unnamed.

The Annotation syntax for references now has a reference keyword; the previous syntax just didn't work. However not all elements can be identified textually so Bug 354621 covers the enhancement to support all references.

The improved code pushed to master for M1 supports the external URI in the example and simple internal named references.
Comment 7 Ed Willink CLA 2013-05-20 11:38:13 EDT
CLOSED after a year in the RESOLVED state.