Hi, Ernesto,
The ‘no null constraint’ problem is definitely a bug. This occurs when attempting to add null to an EList that doesn’t allow nulls (for example, any EObjectEList). It’s easily trapped with a breakpoint in the AbstractEList::validate method, from which you can get a stack trace to report a bug. But the reason why it is happening is probably symptomatic of the underlying issue you’re facing.
In any case, every profile, whether it references another for stereotype superclasses or not, is its own schema that is versioned separately and migrated (more or less) separately. But the UML2 algorithm for the migration probably needs to migrate all interdependent profile schemata together from one consistent version to another consistent version in order to do it correctly. This has come up before in non-Papyrus contexts and without the added complication of unknown schema.
Papyrus tries to emulate the stock UML2 profile migration from an unknown schema (to a known schema) by asking the user for what the target schema is and inferring as well as it can the meaning of things in the model that are presented to it entirely as name/value pairs of strings, in order to correlate them to the target schema. I don't know that it matters to this process whether the unknown schema in question “extends” some other profile or not. All of the information that needs to be migrated is manifest in the XML elements in the model resource as these name/value pairs. I suspect that your scenario would play out the same way even if your profile didn’t extend SysML but implemented all of the SysML stereotypes that it references internally, as an independent profile (perhaps by package merge, heh heh).
That’s about what I can suggest without actually debugging the scenario. Hopefully it gives you a starting point.
On Oct 17, 2017, 16:57 -0400, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
Hi. I'm trying to understand how does the profile migration works, specially when dealing with unknown profiles.
I have a profile which extends the SysML 1.1 profile and I'm migrating it to SysML 1.4, and I have a model which has this new profile (and SysML 1.1) applied. I have observed what seems to be inconsistent behaviour. Sometimes the SysML stereotypes seem to be migrated correctly, although the dialog box issues a warning that these stereotypes could not be found. Sometimes I get a "The 'no null' constraint is violated" and when this happens the fixes do not seem to work. Furthermore, some of the "new" stereotypes of the "unknown" profile seem to be applied correctly, but not all. (I'm trying to make minimal examples to reproduce).
So how does the migration deal with "unknown" profiles? What does it do when it encounters a stereotype from an unknown profile which extends a stereotype from a profile being migrated (e.g. a stereotype S extending the "Block" stereotype in SysML, which is being migrated)? What happens to stereotypes which do not extend stereotypes being migrated?
Thanks
--
Ernesto Posse
Zeligsoft
--
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
