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

Bug 495129

Summary:

EditingDomainServices fails to retrieve the adapter factory for some elements

Product:

[Modeling] Sirius

Reporter:

Cedric Brun <cedric.brun>

Component:

Core

Assignee:

Pierre-Charles David <pierre-charles.david>

Status:

CLOSED FIXED

QA Contact:

Julien Dupont <julien.dupont>

Severity:

normal

Priority:

CC:

julien.dupont, laurent.redor, maxime.porhel

Version:

unspecified

Keywords:

triaged

Target Milestone:

4.1.0

Hardware:

All

OS:

All

See Also:

https://git.eclipse.org/r/79281
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=700952c95dc0cd8c8682a43a23978aaab70c59ab

Whiteboard:

Bug Depends on:

Bug Blocks:

500077

Attachments:

Description	Flags
Projects to import in a workspace reproduce the issue	none
screenshot of a diagram definition applied on Ecore	none
empty eType combo in EcoreTools	none
Screenshot after the fix	none

Description Cedric Brun

2016-06-01 06:10:36 EDT

The context is in EcoreTools + Sirius 4.0.0 .
The problem might not be that visible in other contexts, ecoretools is a bit special in this regard. 

In EcoreTools some model elements are resolved from the EcoreRegistry and might not come from the session's resourceSet : most notably datatypes from Ecore.ecore itself.

In such a case EditingDomainServices.getEditingDomain(EObject) fails to retrieve any editing domain on this object and as such most of the services will fail later one because of the lack of AdapterFactory for those objects.

Comment 1 Laurent Redor

2016-06-03 08:05:39 EDT

Do you have a reproduction case?

Comment 2 Cedric Brun

2016-07-11 09:04:07 EDT

Created attachment 263016 [details]
Projects to import in a workspace reproduce the issue

Comment 3 Cedric Brun

2016-07-11 09:06:34 EDT

Created attachment 263017 [details]
screenshot of a diagram definition applied on Ecore

expected:
- every node should have  a label computed from the label provider of the "EAttribute.eType" value

KO: the one having eType set with EString has no label whereas it should have the EString one.

Comment 4 Cedric Brun

2016-08-05 05:46:56 EDT

Created attachment 263476 [details]
empty eType combo in EcoreTools

Another way to reproduce. 

Install EcoreTools (the Neon release is fine)
EEF and Sirius nightly (including the old runtime which got a few fixes interesting for EcoreTools lately)

Click on en EAttribute
=> the auto-generated rich properties are displaying a combo for eType but it looks empty.

Comment 5 Pierre-Charles David

2016-08-18 11:54:06 EDT

Simpler test:

        EditingDomainServices svc = new EditingDomainServices();
        EDataType eStringType = EcorePackage.Literals.ESTRING;
        String text = svc.getLabelProviderText(eStringType);
        Assert.assertEquals("EString [java.lang.String]", text);

fails with AssertionError: expected:<EString [java.lang.String]> but was:<null>

Comment 6 Eclipse Genie

2016-08-18 12:00:32 EDT

New Gerrit change created: https://git.eclipse.org/r/79281

Comment 7 Eclipse Genie

2016-08-22 11:11:30 EDT

Gerrit change https://git.eclipse.org/r/79281 was merged to [master].
Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=700952c95dc0cd8c8682a43a23978aaab70c59ab

Comment 8 Pierre-Charles David

2016-08-23 04:51:59 EDT

Created attachment 263717 [details]
Screenshot after the fix

Comment 9 Pierre-Charles David

2016-08-23 04:53:09 EDT

Fixed.

See the screenshot for the result: both items have a proper label, and the eType combo is correctly filled (with items correctly displayed).

Comment 10 Pierre-Charles David

2016-10-18 11:08:48 EDT

Available in Sirius 4.1.0, see https://wiki.eclipse.org/Sirius/4.1.0 for details.