| Re: [mdt-papyrus.dev] About the migration to SysML 1.4 |
|
Hi Alain, We cannot get rid of static version of the old profile for legacy purpose. Some users having a methodology based on older versions of SysML may want to keep
using it with Papyrus upcoming releases. Best regards, Chokri
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 |