| Re: [mdt-papyrus.dev] About the migration to SysML 1.4 |
|
Hi Alain,
If we can’t complete this for Mars, at least we can guarantee that we’re not going to break anyone. Moreover, we’re currently investigating on a new method
to implement SysML diagrams as customizations of existing UML Diagrams (Rather than extending them). Since this introduces a lot of hazard, we want to have a clearly separated set of plug-ins, as well as a separate profile, so that users and tool providers
can choose, at their own discretion, whether they want to migrate or not. For the next versions, we will hopefully be able to simply update the SysML 1.4 profile and provide a transparent migration. Of course, this means that we will
either have to keep the “14” suffix, or rename the packages, which is not a good thing in either case. So, we could change this suffix to something else (less version-specific), while still keeping it separate from the current SysML implementation. When we’re confident enough with this new approach for SysML, we can refactor the SysML 1.1/2 plug-ins to only provide a dynamic profile, and deprecate the
current SysML diagram plug-ins; but we’re not there yet Regards, De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Alain Le Guennec Hi all, I have some general remarks about the on-going work to migrate Papyrus to SysML 1.4, which I think are important for advanced consumers of Papyrus that use the static SysML profile(s) extensively. I could have raised them in bugzilla #440082, but maybe this needs a wider discussion. I just saw in gerrit that SysML 1.4 support was implemented as a set of brand new plugins (model, edit, etc), and therefore new Java packages, all prefixed by "org.eclipse.papyrus.sysml14" instead of good old "org.eclipse.papyrus.sysml" I am a bit afraid of the consequences of this choice: I don't like it very much that the profile version be encoded in the corresponding Java packages. It will force all client code of the static profile to be updated (including Papyrus SysML diagram editors), even for those parts that haven't changed. Do you imagine fixing all UML2-dependent code each time the UML2 project migrate to a new version of the UML standard? Will this have to be done again if/when SysML 1.5 or 2.0 is released? Wouldn't it be possible to adopt an approach to versioning more similar to what is done by the UML2 project? I've also noticed that the two deprecated stereotypes (FlowPort and FlowSpecification) have been moved to their own sub-package in the profile. Again, this will impact all client code to use classes from package "org.eclipse.papyrus.sysml14.deprecatedelements". Moreover, section C3.2 of the SysML 1.4 specification does not mandate a separated package for those 2 stereotypes. On the contrary, it states that those two stereotypes still belong to package Ports&Flows, like they always did. Since they were kept as deprecated to ease migration, I would make sense to also leave them where they were in the Java namespace, to ease Java code migration too, and just have them marked as @Deprecated to identify the risk of still using them. I can understand that there are advantages to having different Java namespaces for two different versions of the static APIs, if only to have both sets of classes available in a single class loader to write migration code in Java, for example. But instead, the old version(s) of the profile could maybe be kept as dynamic profile(s), while only the most recent version would be static, with a constant Java namespace. That way, in a context with both old and new stereotype applications, legacy ones could still be accessed as DynamicEObject, and manipulated as usual via any mechanism based on dynamic EMF. What do you think? Best regards, -- Alain Le Guennec, R&D Expert Engineer SCADE System Project Manager Esterel Technologies, a wholly-owned subsidiary of ANSYS, Inc. Tel: +33 5 34 60 90 55 |