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

Bug 387704

Summary: [Control Mode] Controlling a package leaves the stereotypes applied to the package in the parent files
Product: [Modeling] Papyrus Reporter: Alain Le Guennec <alain.leguennec>
Component: CoreAssignee: Project Inbox <mdt-papyrus-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: cletavernier, eclipse-bugzilla
Version: 0.9.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=389495
Whiteboard:
Attachments:
Description Flags
Patch to fix the issue. vincent.lorenzo: iplog+, vincent.lorenzo: review+

Description Alain Le Guennec CLA 2012-08-21 11:10:31 EDT
If you control a package to a new file, the stereotype applications for the package's child elements are correctly moved to the new file, but not the stereotype applications pertaining to the package itself (they are left in the package parent's file).
Comment 1 Alain Le Guennec CLA 2012-08-21 11:37:55 EDT
Created attachment 220108 [details]
Patch to fix the issue.

Note that ideally, the method relocateStereotypeApplication(Element, EObject) now provided in this patch to implement stereotype application relocation should follow the same hookable strategy as stereotype application creation does, as implemented in class org.eclipse.uml2.uml.util.UMLUtil.StereotypeApplicationHelper.
Unfortunately, as mentionned within comments in the patch, the method getContainmentList() of StereotypeApplicationHelper is not public, so I cannot call it without overriding the whole StereotypeApplicationHelper (which I did in my own version, but seemed a bit overkill for Papyrus, all the more since overriding the StereotypeApplicationHelper via the dedicated System property must be done very carefully in an OSGi environment where bundle activation order is hard to predict).

Maybe the best solution would be to move the "relocateStereotypeApplication" method within UML2's StereotypeApplicationHelper class altogether, properly using getContainmentList to determine the new destination location of the stereotype application.
Kenn, if you are listening, what would you think about that?

Anyway, the usual disclaimer:
(1) I, Alain LE GUENNEC, 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 2 Vincent Lorenzo CLA 2012-09-10 11:03:44 EDT
Commited in R8953 on trunk and branch.
Comment 3 Vincent Lorenzo CLA 2012-09-10 11:04:38 EDT
Comment on attachment 220108 [details]
Patch to fix the issue.

Committed in R8953