Eclipse Sphinx 0.8.0

The Sphinx 0.8.0 release is focused on some functional enhancements as well as on bug fixes and flexibility/performance improvements. The most prominent functional enhancements include:

XML persistence mapping based XML serializer and XSD generator for EMF models

This is a new component in Sphinx that enables metamodel designers to customize the structure of the XML documents used to persist EMF model instances in a highly flexible way and generate a corresponding XSD schema. The basis for this customization are dedicated XML persistence mapping annotations which can be added to the classes and features of the underlying Ecore metamodel. The annotated Ecore metamodel is used for two things: At runtime, it drives the serialization/deserialization of EMF model instances into/from XML documents with the intended custom structure, and at design time, it controls the generation of the XSD schema that describes the custom XML structure formally and can be used to validate the XML documents containing the serialized EMF model instances.

From a principle point of view this goes into the same direction as what can be done with the ExtendedMetaData annotations supported by the EMF Core framework. However, the extent to which XML document structures can be customized using ExtendedMetaData annotations is somewhat limited. Compared to that, XML persistence mapping annotations allow for much more flexibility and expressiveness and enable EMF Ecore metamodels to be mapped to XML document structures that are as complex as those defined by AUTOSAR [1] or EAST-ADL [2].

[1] http://www.autosar.org

[2] http://www.east-adl.info

Cross-metamodel referencing support

Sphinx has the intrinsic policy that the model files for every metamodel get loaded into their own editing domain/resource set (which may or may not be customized in a way that is specific to the metamodel in question). This has been working out fine as long as cross-document references existed only between model files that are based on the same metamodel and end up in the same Sphinx-managed editing domain/resource set. However, some Sphinx adopters have come up with use cases where it has been necessary to provide support for cross-document references between model files of different metamodels. Given that Sphinx loads the model files into different editing domains/resource sets in this case, there was no out-of-the-box way to resolve such cross-metamodel cross-document references.

To support such scenarios without breaking the way how Sphinx organizes the mapping of model files to editing domains/resource sets, Sphinx has been enhanced to support the resolution of cross-document references across different resource sets. This comes down to that cross-document references between to model elements from the same metamodel are resolved as usually, i.e., within the resource set of the model element at the source end of the cross-document reference. But when it happens that the model element being referenced is based on a different metamodel than the model element by which it is referenced, the resolution of the cross-document reference gets transparently delegated to the resource set behind the model element at the target end of the cross-document reference.

Improved integration of UML2

In order to improve the usefulness of Sphinx for handling UML2 models, a couple of improvements have been implemented.

These include the deprecation of some Sphinx APIs which were based on the obviously invalid assumption the a model resource always contains only a single root element. When using them with multi-rooted model files (which happens quite frequently when working with UML2 files), this limitation entailed that only the first root element became available in Sphinx and were accessible through the Sphinx UI (Model Explorer, form editors, etc.) whereas all subsequent root elements were ignored. Therefore, all Sphinx APIs contributing to this limitation were replace by new APIs supporting single- and multi-rooted model files (e.g., EcorePlatformUtil#loadModelRoot(IFile, Map) : EObject was replace by EcorePlatformUtil#loadResource(IFile, Map) : Resource).

Another enhancement has been made to ensure that UML2 models can take advantage of Sphinx' advanced resource scoping capabilities enabling different instances of the same metamodel to be managed and distinguished within the Eclipse workspace. Most importantly, this guarantees that cross-document references between different model files get only resolved within the set of resources that belong to the same model instance but not within all resources that are present in the workspace. However, this feature implied that the underlying metamodel implementation extends Sphinx' ExtendedEObjectImpl or ExtendedMinimalEObjectImpl instead of EMF's EObjectImpl or MinimalEObjectImpl as EObject root class. While this may be acceptable for a metamodel that one develops on one's on behalf, it becomes impossible to do so for metamodels that already exsist and have been created by a third party, such as UML2. To overcome this issue, the proxy resolution capabilities in Sphinx' ExtendedResourceSetImpl have been significantly enhanced. As a result, it is now possible to benefit of full resource scoping support with metamodels that are purely based on EMF and don't extend any Sphinx classes. But as often in live, this extra flexibility does not come totally for free. The price to pay consists in longer proxy URIs for unresolved model element references because Sphinx need's to store some context information that is vital to the resource scoping capability in the query strings of the proxy URIs. When working with models that have many unresolvable references this can lead to a significantly increased memory consumption. For this reason, the existing approach to leveraging the Sphinx resource scoping capability has been left in place. So, metamodels that don't "mind" extending ExtendedEObjectImpl or ExtendedMinimalEObjectImpl and pulling in a dependency on Sphinx can continue to do so and enjoy full resource scoping support without entailing that the longer context-aware proxy URIs need to be used and possibly provoke an increased memory consumption.