Eclipse Sphinx 0.11.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.

Wednesday, June 21, 2017

The Sphinx 0.10.0 release is focused on some functional enhancements as well as on bug fixes.

The most prominent functional enhancements include:


Eclipse Sphinx 0.11.0


The Sphinx 0.11.0 release is focused on some functional enhancements as well as on bug fixes.

The most prominent functional enhancements include:

Launching support for Sphinx Workflows

Up to now, Sphinx workflows could be launched by right-clicking workflow files or model elements/files in the Sphinx Model Explorer and using the ''Run Workflow...'' context menu item. However, this approach was limited in the sense that users always must navigate to the model element/file they wanted the workflow to operate on. They also had to reselect the workflow to be run each time anew, and it was not possible to specify and pass any additional arguments to the workflow. To address these issues, a new launch configuration type ''Sphinx Worklow'' has been introduced. It enables users to define, memorize and invoke recurrent combinations of workflow, model element/file and optionally additional workflow arguments. These launch configurations can be invoked through the usual Eclipse menus and toolbar buttons as any other launch configuration. Alternatively, they can be invoked on the command line. Therefore, a headless launcher application has been made available that enables launch files behind Sphinx Workflow or any other launch configuration to be invoked in non-interactive batch processes.

Simplification in applying Viatra Query-based Sphinx features to user-defined metamodels

Sphinx comes with Viatra Query-backed model search and proxy resolution services. In order to use them for a given metamodel, users had to complement them with self-written (or generated) and quite repetitive Viatra Query patterns covering all relevant element types of the metamodel in question. However, the functionality behind those Viatra Query patterns can also be obtained by using the Viatra Query Base Index (which is also used by the Viatra Query engine). Therefore, the Viatra Query integration in Sphinx as well as model search and proxy resolution implementations based on it have been completely refactored. The formerly used metamodel-specific Viatra Query patterns have been replaced by corresponding generic implementations leveraging the Viatra Query Base Index. As a result, users don't need to provide any metamodel-specific Viatra Query patterns at all now. They can benfit of the Viatra Query-backed Sphinx services for any metamodel by simply using the Sphinx-provided out-of-the box service implementations instead. This greatly reduces the complexity and effort behind the application and use of Viatra Query-backed Sphinx services to user-defined metamodels.

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" adopters 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 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 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 [1]. While mainly having been used indirectly through Artop [2] (an Sphinx-based tool platform supporting the development of design tools for the AUTOSAR standard [3]) 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 use of Sphinx happens in the EATOP project [4]. It provides to tool platform supporting the development of design tools for the EAST-ADL standard [5] and is entirely based on Sphinx.






This release is part of Eclipse Oxygen.