0.10.0
The Sphinx 0.10.0 release is focused on some functional enhancements as well as on bug fixes.
The most prominent functional enhancements include:
Model Split Service
A capability allowing resources or model object contents to be traversed and distributed over multiple resources according to user-defined model split policies.
Access to the "ordered" attributes in metamodels and "ordered"-based sorting in Common Navigator-based views
An extended BasicExtendedMetaData implementation that allows an extra "ordered" flag to be specified for and retrieved from structural features of Ecore metamodels. Can be used as safe place to put the conceptional "ordered" information instead of the structural features' ETypedElement#ordered attribute whose setting is typcially rather driven by technical constraints.
The common navigator integration for EMF models provided by Sphinx has been extended to prevent the model objects being displayed from being automatically sorted in alphabetical order everywhere. Instead, it evaluates the extra "ordered" annotation on the underlying structural features and maintains the original order of the values in the model in case that it is set.
Metamodel and view content agnostic problem decorator for model elements
A generic label decorator for Common Navigator-based views in Sphinx that decorates all resource and model object items on tree paths containing model objects affected by validation warnings or errors with appropriate overlay icons. Does neither depend or make any assumptions on the structure of the underlying metamodel(s) nor on that of the content provider exposing the model objects and fully supports tree contents where referenced model objects are displayed as children of their referrers.
Reusable base implementation of an IURIChangeDetectorDelegate for URIs with hierarchical fragments
Makes it easy to add URI change detection support for models being persisted resources that rely on URIs with hierarchically structured fragments for representing cross-references between model objects. As a result, Sphinx can automatically analyze the changes being made on the loaded models, determine all model objects whose URIs are impacted by these changes and rewrite not only all directly changed resources upon saving but also all resoures that will need to updated because they contain cross-references to changed model elements.
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.
None.
Examples have been updated and kept in sync with the changes and enhancements that have been realized in the related Sphinx components and services.
No significant changes.
None.
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].
[1] http://www.w3.org/TR/xml
[2] http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405
[3] http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405
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 adoption of Sphinx has been made by the recently started 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.
[1] https://wiki.eclipse.org/Auto_IWG
[2] https://www.artop.org
[3] http://www.autosar.org
[4] http://eclipse.org/eatop
[5] http://www.east-adl.info