Community
Participate
Working Groups
In order to get the MDT/OCL JUnit tests to pass for M2, it is necessary to add } else if ("PrimitiveTypes::Boolean".equals(qualifiedName)) { //$NON-NLS-1$ eType = EcorePackage.Literals.EBOOLEAN; to UMLUtil.UML2EcoreConverter.getEType(Type type) Presumably all 5 new names need mapping. The PrimitiveTypes::Boolean originates from \GIT\org.eclipse.ocl\tests\org.eclipse.ocl.uml.tests\model\OCLTest.uml that contains <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#Boolean"/>
Actually, the built-in UML primitive types now have their own metamodel, so the mapping should be } else if (qualifiedName.startsWith("PrimitiveTypes::")) { //$NON-NLS-1$ eType = TypesPackage.eINSTANCE.getEClassifier(type.getName());
The startsWith enables you to pick up all 5 mappings at once, but the subsequent mapping is not the same. The traditional behaviour is to convert to EString etc. However there is a user choice, and so for OCLinEcore, to support OMG usage, I had to enhance the Save As Ecore, to support a Save in Ecore option in which String stayed as String. Perhaps there needs to be a processing option, but I think most Ecore users will want EString and EBoolean although of course the mapping for Integer is far from obvious; traditional OCL is EInt, the new pivot OCL is EBigInteger.
Hmm. After closer inspection, I'm inclined to think that the current behavior is correct, given the existence of the new Types package. As it stands now, the UML types are correctly mapped to their counterparts in the new package. I realize this is a deviation from the previous ("traditional") behavior, but this isn't the only thing that's changed in UML2 4.0... FWIW, I did try to map the built-in types Ecore types but ran into the unfortunate side-effect that I could no longer produce the source models for UML2 (where it is indeed desirable to end up with non-Ecore types)...
I'm happy with a WONTFIX. I suspect I just need to modify OCLTest.uml to use EcorePrimitiveTypes.library rather than UMLPrimitiveTypes.library. However for EMF, Ed is usually pretty paranoid about preserving traditional behaviour, so perhaps, in recognition of the new package a new PrimitiveTypes.library or Types.library is new and the old are old with UMLPrimitiveTypes.library being deprecated.
Changes to map the UML primitive types to the new Types package (along with implicit support for them in the UML2 code generator) have been committed and pushed. I don't see the need to go to great lengths to be backwards compatible in this regard given that it's a major release and is already binary (and API) incompatible...
