Support Metamodel migration, POJO datatype and feature serialization ordering

[vrichard12]

This issue addresses the following subjects:

• Handling the renaming of EAttribute
  The metamodel migration API should allow to handle the renaming of an EAttribute

• Handling a type change or a value change of an EAttribute
  The metamodel migration API should allow the migration of value and the changing of type of EAttributes.

• Support for Serialization / deserialization of POJO EDataType
  Custom data types with instance type set to a POJO class needs to be serialized to / deserialized from json.taType()`

• Add a comparator option on the JsonResource to determine the order in which features are serialized.

[sbegaudeau]

• This looks like at least four issues and not one
• Why would custom data types need to be serialized / deserialized using json.taType() (???) and why isn't the factory of the meta model in question handling the data type?

[vrichard12]

• We don't have much budget left to split this PR into 4. I'm not sure how we could handle that.
• 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 produce a json object structure.
  I don't understand how the meta-model factory could be of any help.

[sbegaudeau]

If you have a meta model with a custom datatype which can be an enum or not, for example in the official library sample from EMF:

• The datatype BookCategory is defined in the metamodel
• The factory generated thus contain the relevant methods to load / save the datatype

There are countless of metamodels out there that are handling by themselves how to save/load the value of their datatypes, here is one case from UML for example. If you define a custom datatype in your meta model, you are in charge of its serialization/deserialization by overriding the relevant methods in your factory XxxFactoryImpl#createYyyFromString and XxxFactory#convertYyyToString. By default, EMF cannot do much more than object.toString() to save the object of course.

We cannot break the serialization of all those metamodels

[vrichard12]

You're so right! Thank you for this feedback.
The solution should involve overriding the fromString and toString methods, that's all.
I'll come back to you later.

[vrichard12]

Hi Stephane,

Actually it is not that simple because EFactory.convertToString() is called in the existing GsonEObjectSerializer.serializeEDataType() method, which is supposed to return a JsonElement and not a String. In addition, I think the factory should be resource type agnostic.

What was initially done in GsonEObjectSerializer.serializeEDataType() was to instantiate a JsonPrimitive with the return value of EFactory.convertToString(). This is fine as long as we are only dealing with primitive types, but when it comes to POJO, if convertToString() returns a json string then do we need to deserialize it into a JsonElement before returning it?
I don't think so. This would impose that convertToString() returns a json string, which would break the resource type agnostic principle for the EFactory.
There is no room for customizing the way a POJO DataType is serialized to a json string in the EFactory. If the EFactory.convertToString() is overridden, that's fine, and I agree that the overridden value should be used. But then its value must be treated as a JsonPrimitive. We cannot assume that the returned value is a consistent json string. It is the responsibility of the JsonResource to generate a valid Json structure.

Therefore, we have to find a way to detect that the EAttributeType is a POJO datatype, and that the convertToString() has not been overridden to generate a JsonTree in this case. Any other case must be treated as a primitive type value.

Identifying if the EAttributeType is a POJO datatype is done by testing if the instance class of the EAttributeType is not null because every other case of primitive types and enumeration has been handled in GsonEObjectSerializer.serializeEAttribute().
And testing that convertToString() has not been overridden is done with the test value.toString().equals(stringValue).

I have updated the commit accordingly, please take a look when you get a chance.