The kind properties of the following metaclasses have enumeration types, but no default in the MOF abstract syntax model, even though they also have a multiplicity lower bound of 1:
RequirementConstraintMembership
TriggerInvocationMembership
StateSubactionMembership
TransitionFeatureMembership
However Eclipse still normally generates a KIND_EDEFAULT constant for these properties in the corresponding implementation classes that is set to the first enumeration literal of the corresponding type. This means that the XMI generated for these relationships did not include a kind value in the case it was one of these defaults. This pull request updates these implementation classes so that KIND_EDEFAULT is set to null. As a result, kind is always serialized in XMI for these metaclasses (but see below).
The subclasses FramedConcernMembership and RequirementVerificationMembership of RequirementConstraintMembership redefine kind to give it the default requirement, which is actually the value that kind must always have for these relationships. However, this redefinition is lost in the Ecore metamdeol, and the default from RequirementConstraintMembershipImpl is inherited by the implementations of the specialized relationships.
This pull request updates the generated eIsSet method in the corresponding implementation classes so that kind is always considered "not set" for FramedConcernMembership and RequirementVerificationMembership, which means that kind is considered to always have its "default" value and is not serialized in XMI.
The getKind method is also overridden to always return requirement.
The
kindproperties of the following metaclasses have enumeration types, but no default in the MOF abstract syntax model, even though they also have a multiplicity lower bound of 1:RequirementConstraintMembershipTriggerInvocationMembershipStateSubactionMembershipTransitionFeatureMembershipHowever Eclipse still normally generates a
KIND_EDEFAULTconstant for these properties in the corresponding implementation classes that is set to the first enumeration literal of the corresponding type. This means that the XMI generated for these relationships did not include akindvalue in the case it was one of these defaults. This pull request updates these implementation classes so thatKIND_EDEFAULTis set tonull. As a result,kindis always serialized in XMI for these metaclasses (but see below).FramedConcernMembershipandRequirementVerificationMembershipofRequirementConstraintMembershipredefinekindto give it the defaultrequirement, which is actually the value thatkindmust always have for these relationships. However, this redefinition is lost in the Ecore metamdeol, and the default fromRequirementConstraintMembershipImplis inherited by the implementations of the specialized relationships.eIsSetmethod in the corresponding implementation classes so thatkindis always considered "not set" forFramedConcernMembershipandRequirementVerificationMembership, which means thatkindis considered to always have its "default" value and is not serialized in XMI.getKindmethod is also overridden to always returnrequirement.