Eclipse Sphinx 0.9.0

Release Date
Deliverables

The release's deliverables will include the following items:

  • The source code (available via a tag named 0.9.0 in the project's Git repository)
  • An p2 repository (available via the project's update site or as downloadable zip archive file) including
    • Runtime binaries
    • Sources
    • Developer documentation
    • Examples
    • Test utilities
    • Required third party bundles
Compatibility

This release will be developed in parallel, and released simultaneously, with the Eclipse projects it depends on for the Eclipse Mars release. Each milestone build will be compatible with the corresponding milestones for each of these projects, and delivered at the appropriate offset. The release will be binary and source compatible with the previous Eclipse Luna release.

Internationalization

Sphinx is designed as the basis for internationalized products. The user interface elements provided by the Sphinx components, including menu items, dialogs and problem messages, are externalized. The English strings are provided as the default resource bundles. Currently no other translations exist.

Target Environments

Sphinx depends upon on the Eclipse Platform and other projects, which are mostly "pure" Java. Sphinx therefore targets the same underlying operating environments and versions as the Eclipse plaform does. Being written and compiled against version 1.6 of the Java Platform APIs, this relase of Sphinx is targeted to run on version 1.6 or higher of the Java Runtime Environment, Standard Edition.

Name Date Description
M1 2014/08/22
M2 2014/10/03
M3 2014/11/14
M4 2014/12/19
M5 2015/01/30
M6 2015/03/20
M7 2015/05/08
RC1 2015/05/22
RC2 2015/05/29
RC3 2015/06/05
RC4 2015/06/12
Themes

Performance

Sphinx already includes many optimizations to improve the runtime performance when it comes to handling and processing bigger models (e.g., file content type detection, model loading or unloading). Nevertheless, further and potentially quite significant performance improvements could be achieved by introducing a model indexing service in Sphinx and using index-backed queries to perform runtime-intensive operations on EMF models (e.g., proxy resolution, model validation, deletion of model elements).

Interoperability

One of the key advantages of Sphinx is that it enables the creation of integrated model-driven tool environments based on multiple metamodels or Domain-Specific Languages (DSLs) and thereby provides a very good interoperability between them. This is an important capability for users who need to work on multiple aspects of a system (e.g., requirements, functional architecture, software architecture, safety) with each of them involving the usage of a specific modeling language or standard. However, so far this interoperability can only be leveraged with modeling tools that are actually based on Sphinx and reuse its common modeling tool backbone, i.e., the Sphinx model workspace management. It would be very useful and a significant step forward if the cross-metamodel/cross-DSL interoperability offered by Sphinx could be extended to non-Sphinx-based modeling tools or even to non-Eclipse-based modeling tools. This could be achieved by providing appropriate connectors and model data exchange services based on the Open Service for Lifecycle Collaboration (OSLC) standard.

Architecture

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.
This release is part of Mars