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

Bug 359795

Summary:

[EFacet] Facets can't be correctly used when we extends an object of a parent meta-model

Product:

z_Archived

Reporter:

Vincent Lorenzo <vincent.lorenzo>

Component:

EMF-Facet

Assignee:

Gregoire Dupe <gdupe>

Status:

CLOSED FIXED

QA Contact:

Severity:

major

Priority:

CC:

emft.facet-inbox, gdupe

Version:

unspecified

Flags:

gdupe: indigo+
gdupe: juno+
gdupe: kepler+

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

359793

Attachments:

Description	Flags
This patch corrects the bug (file FacetContext)	gdupe: iplog-, gdupe: review-
This plugin provides a facet to reproduce easily the described bug	gdupe: iplog-
Another path proposition	gdupe: iplog+

Description Vincent Lorenzo

2011-10-04 03:46:35 EDT

Steps to reproduce : 
	1/ Create a facet which extends EObject
	2/ Add a facetReference to display the eClass of the EObject
	3/ Create a new table
	4/ Edit this table in another table
	5/ Apply the facet to this table
		-> the column is created with N/A.
		
	Note : we get the same kind of problem with the Papyrus Model Browser : When an uiCustom defined on EObject calls a facet defined on EObject, the facet is not applied for an UML element. The correction is the same in the 2 cases.

Comment 1 Vincent Lorenzo

2011-10-04 03:55:46 EDT

Created attachment 204490 [details]
This patch corrects the bug (file FacetContext)

(1) I, Vincent Lorenzo, wrote 100% of the code I've provided.
(2) This code contains no cryptography
(3) I have the right to contribute the code to Eclipse.
(4) I contribute the content under the EPL.

Can you commit this patch for SR2 or for Juno?

Best Regards, 
-- 
Vincent Lorenzo

Comment 2 Vincent Lorenzo

2011-10-04 04:40:45 EDT

Created attachment 204494 [details]
This plugin provides a facet to reproduce easily the described bug

(1) I, Vincent Lorenzo, wrote 100% of the code I've provided.
(2) This code contains no cryptography
(3) I have the right to contribute the code to Eclipse.
(4) I contribute the content under the EPL.

Comment 3 Gregoire Dupe

2011-10-04 15:23:59 EDT

Created attachment 204546 [details]
Another path proposition

Vincent,

I do not understand the goal of your patch. The method org.eclipse.emf.ecore.EClass.isSuperTypeOf(EClass) should do a good job (excluding the case of EObject). That’s why I suppose that a test on EObject would be enough.

What do you think of my proposition?

Regards,
Grégoire

Comment 4 Vincent Lorenzo

2011-10-05 03:49:02 EDT

Hi Grégoire, 
 you're right, my patch was too complex for that! Your test on EObject is efficient and sufficient.
 
 Regards, 
 Vincent

Comment 5 Gregoire Dupe

2012-08-16 16:06:07 EDT

Comment on attachment 204546 [details]
Another path proposition

This patch doesn't cause any test regression.

I've then committed this patch.

Trunck: Committed revision 2664.
Branch 0_2_1: Committed revision 2665.

Comment 6 Gregoire Dupe

2012-08-16 16:06:55 EDT

This bug can be marked has fixed.

Comment 7 Vincent Lorenzo

2012-10-09 10:27:50 EDT

This bug can be marked as closed fixed.