Eclipse Sphinx 0.8.0 Release Review

End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.




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].



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.


Architectural Issues

Sphinx is extensible through several dedicated extension points and allows adopters to override, enhance or customize close all of its out-of-the-box services through numerous overriding points (protected methods).

Sphinx still has some architectural issues entailing that the usage of its core plug-ins/feaures pulls in quite some additional dependencies. In particular, in addition to EMF, Sphinx "forces" adapters to use also Eclipse Platform and EMF Transaction. To overcome this problematic and facilitate the adoption of Sphinx in situations where the usage of additional dependencies other than EMF is not acceptable (e.g., Java standalone applications), a refactoring of the Sphinx architecture will have to be conducted. Some preparatory activities in that direction have already been started, and the plan is to get this architecture refactoring done and to come up with well-organized dependencies and a incrementally consumable plug-in/feature set until the next release of Sphinx.

Security Issues


Non-Code Aspects

Examples have been updated and kept in sync with the changes and enhancements that have been realized in the related Sphinx components and services.

Usability Details

No significant changes.

End of Life

The model compare and merge support in Sphinx that was based EMF Compare 1.3 has been removed in this Sphinx release. The primary reason for doing so was that EMF Compare 1.3 has been replaced by newer generations of the framework with significant changes in the core APIs in the Eclipse Kepler and Luna release trains. Keeping the previously existing model compare and merge support in Sphinx would have required a major development effort to migrate it to the latest generation of EMF Compare. However, none of the current users, contributors and committers of Sphinx was able/willing to spend this effort at this time.

Some Sphinx APIs, that were based on the asumption that a model resource always contains only a single root element, have been deprecated and replaced by new APIs that don't underly this limitation (see [1] for details).

[1] bug


The customizable XML serialization for EMF models that is adjustable through XML persistence mapping annotations on the underlying Ecore metamodel is based on the Extensible Markup Language (XML) 1.0 [1].

The newly introduced XSD schema generator for Ecore metamodels that can be controlled through XML persistence mapping annotations is based on the W3C XML Schema Definition Language (XSD) 1.1 [2], [3].





Sphinx is still primarily used in - though in no way limited to - the automotive industry. While mainly having been used indirectly through Artop [1] (an Sphinx-based tool platform supporting the development of design tools for the AUTOSAR standard [2]) in its beginnings, Sphinx now is more and more also used for developing integrated tool support around arbitrary metamodels in different automotive and non-automotive projects and applications.

An important adoption of Sphinx has been made by the recently started EATOP project [3]. It provides to tool platform supporting the development of design tools for the EAST-ADL standard [4] and is entirely based on Sphinx.

Two new committers have joined the Sphinx project in this release cycle: Yue Ma, and Mark Brörkens.





This release is part of Luna

Release Review