Re: [mdt-papyrus.dev] Highest-priority provider in State Machine blocks

[LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx>]

Chris,

Your proposition songs good to me. We had a similar difficulty with SysML14.

Nevertheless I do not know how to evaluate the impact of such change.

RC3 is released

So why not go on your proposition.

Francois

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 1 juin 2016 18:35
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [mdt-papyrus.dev] Highest-priority provider in State Machine blocks customization

 

Hi, Team,

 

Why does the State Machine Diagram define its custom edit-part provider at highest priority?

 

   <extension point="org.eclipse.gmf.runtime.diagram.ui.editpartProviders" id="ep-provider">

      <editpartProvider class="org.eclipse.papyrus.uml.diagram.statemachine.custom.providers.CustomUMLEditPartProvider">

         <Priority name="Highest”/>

          …

      </editpartProvider>

   </extension>

 

This makes it impossible for applications like Papyrus-RT that are building on Papyrus to customize the behaviour of this diagram in their context.  The base implementation of a diagram should always use lowest priority.

 

What would happen if I knocked this down to lowest priority before Neon RC4 (after deleting the other edit-provider that the diagram doesn’t need)?

 

Thanks,

 

Christian

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature