Re: [papyrus-rt-dev] Advice Missing since Oxygen Adoption

[Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx>]

Hi team,

I agree with the analysis from Christian. For the migration, I had to in some sort duplicate the list of element types configurations referenced by UML, and get the same list for Papyrus-RT. That means that we have to take care of what is happening in the UML definitions, so we can keep up⁻to-date with the latest element type additions.

 

This seems like a weakness in the design of the architecture framework, or at least, there should be a sentry to watch out for any modification of the architecture models. As the definition can be spread out in multiple file (architecture models are "merged" at runtime), it may be interesting to have a JUnit test verifying that the current active configuration has not evolved since last "review". We could as a first level test that list of ElementTypeConfiguration available from UML context has not changed from a predefined list or from the UML-RT context.

Cheers,

Rémi

2017-05-26 21:36 GMT+02:00 Christian Damus <give.a.damus@xxxxxxxxx>:

Hi, Team,

One consequence of the adoption of the Papyrus Oxygen platform recently was that now the element-types framework has firewalled Papyrus-based applications such as UML and UML-RT.  This is something that we’ve wanted for quite some time, but it does also mean that now we get less editing behaviour “for free” because we must now register for ourselves any common advice that Papyrus UML uses that we also need.  One such example is the NotationViewDependentsAdvice from GMF that ensures deletion of views in diagrams of elements being deleted.  This was bug 516755, which is now fixed by registering the advice in our element-types model in our UML-RT context.

What other such generic advice had we been relying on inheriting from Papyrus that has now gone AWOL?  I doubt that this was the last case, but probably Rémi has already covered several, so perhaps this is just a reminder to think of changes in advice binding when analyzing apparent regressions.

Cheers,

Christian

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Remi Schnekenburger

Senior Software Architect / General Manager

EclipseSource Paris

Email: rschnekenburger@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris 
Phone: +33 1 85 41 08 65

Hangouts: rschnekenburger@xxxxxxxxxxxxxxxxx

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger

Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France

Commercial Register 824 977 516  R.C.S. EVRY