[22] Support Metamodel migration, POJO datatype and feature serialization ordering

[vrichard12]

Addresses the following subjects:

• Handling the renaming of EAttribute Renaming of EAttribute is handled by the ExtendedMetaData.getElement() API. Examples of such a migration is provided in the org.eclipse.sirius.emfjson.tests.internal.unit.load.ExtendedMetaDataAttributesLoadTests test class.

• Handling a type change or a value change of an EAttribute Changing the type or the value of an EAttribute is handled with the JsonHelper.setValue() API. Exemple of such migrations are provided in the org.eclipse.sirius.emfjson.tests.internal.unit.load.JsonHelperDataLoadTests test class.

• Support for Serialization / deserialization of POJO EDataType Custom data types with instance type set to a POJO class are serialized to / deserialized from json. The corresponding tests are : org.eclipse.sirius.emfjson.tests.internal.unit.load.DataTypeLoadTests.testLoadSingleValueAttributePojoDataType() org.eclipse.sirius.emfjson.tests.internal.unit.load.DataTypeLoadTests.testLoadMultiValuedAttributePojoDataType() org.eclipse.sirius.emfjson.tests.internal.unit.save.DataTypeSaveTests.testSaveSingleValueAttributePojoDataType() org.eclipse.sirius.emfjson.tests.internal.unit.save.DataTypeSaveTests.testSaveMultiValuedAttributePojoDataType()

• A comparator option on the JsonResource to determine the order in which features are serialized org.eclipse.sirius.emfjson.tests.internal.unit.save.SerializeOptionsTests.testSerializationWithFeatureOrderComparator()

[vrichard12]

fixes #22

[vrichard12]

As I said in the associated issue #22, before this evolution, the POJO serialization felt back to a toString() call, producing this kind of string: org.obeonetwork.some.package.SomeType@147c1776. What we want is to be able to handle a json object structure in order to be fully compliant with the json format. We need a custom serialization mechanism on top of the EMF one to handle the Json format. That's the purpose of JsonResourceImpl. All we do here is add the support for a corner case that wasn't handled: custom datatypes with an instance type name referring to a POJO.

[sbegaudeau]

I've merged 90% of the commits of this pull request as part of the pr #31 and performed the release of EMFJson 2.3.6. This way, we can continue our discussion regarding the last commit since I still have some issues with the code.

[vrichard12]

Hi Stéphane,

To get everyone in agreement, I've set up an option to specify which POJO should be considered by Json serialization/deserialization (OPTION_IS_EDATATYPE_SERIALIZABLE_IN_JSON_TESTER).

You'll notice that I've also avoided calling super.getElement() in the BasicExtendedMetaData subclasses to avoid falling into the XMI-specific processing that has been implemented in BasicExtendedMetaData.

Finally, I had to correct a behavior in GsonEObjectSerializer.serializeEDataType() in the case of a single-valued attribute. When the stringValue was null, the code created a JsonPrimitive(""). This poses a problem when serializing POJO type attributes, where it cannot be serialized as the empty string. When the default value of an attribute is null, and the value of the attribute in the model to be serialized is also null, nothing should be serialized.