Sphinx provides a relatively large set of services and uses or extends a wide set of other Eclipse (modeling) components. Adopters may not need all of these services or required Eclipse components in their applications. Sometimes they even might be constraint to not using some of them. Sphinx is therefore based on an architecture that makes the dependencies wrt required Eclipse components transparent and keeps them separated as much as possible. This architecture is at the same time the basis for the structure of the features in which Sphinx plug-ins are bundled up and delivered. The resulting features thus have well-defined and limited dependencies to other Eclipse components and make it happen that individual parts of Sphinx can be used independently of each other.
The following picture depicts the Sphinx architecture. It is constituted of 3 horizontal layers that form together the Sphinx core and several vertical slices on top of that. The core components provide essential modeling platform services that are commonly required and used by all other Sphinx components. They depend on a minimal set of other Eclipse components. The vertical components provide individual modeling platform services that are independent of each other and typically based on specific additional exisiting Eclipse components.
Sphinx components may have dependencies to other Sphinx components and/or to other Eclipse (modeling) components. The dependencies to other Sphinx components are depicted in the architecture diagram above (upper components depend on lower components). The table below lists the dependencies to other Eclipse components. For the sake of a better overview, only directly required Eclipse components are listed.
|Top-level service||Sub services||Dependencies to other Eclipse components|
|Navigator & Editor Sockets||Common Navigator Sockets||
|Form Editor Sockets||
|Nebula Extensions for Form Editors||
|GMF Editor Sockets||
|Validation Runtime Extensions||
|M2x IDE Integration||Xtend/Xpand IDE Integration||
|EMF Runtime Extensions||
|Eclipse Platform Extensions||
The structure of Sphinx features is on the one hand based on the Sphinx architecture introduced above and on the other hand designed to separate the different types of deliverables, i.e., runtime, SDK, examples, etc. It is hierarchically organized and decomposed into three principal kinds of features: root features, component features, and example features. Adopters can freely choose which of these feature types they want to refer to and thus have full control over the Sphinx components and deliverables that get included in their applications.
The sections below summarize the root, component, and example features that Sphinx provides and briefly describe their content and relation to the Sphinx architecture. A complete specification of the Sphinx features including detailed information about included features and plug-ins can be found in the Sphinx Feature Map.
Root features are the primary deliverables of Sphinx and can be used to consume all or predefined subsets of Sphinx components or examples at once. They can be individually retrieved from the Sphinx Update Site or obtained as individual archives from the Sphinx Downloads. The following root features are provided:
|org.eclipse.sphinx||Runtime (i.e., binaries without source code and documentation)||All component features as per #Component features except Nebula Extensions|
|org.eclipse.sphinx.sdk||SDK including runtime, source code and documentation (but no examples)||All component features as per #Component features except Nebula Extensions|
|org.eclipse.sphinx.nebula||Nebula Extensions Runtime (i.e., binaries without source code and documentation)||Nebula-related component features as per #Component features|
|org.eclipse.sphinx.nebula.sdk||Nebula Extensions SDK including runtime, source code and documentation (but no examples)||Nebula-related component features as per #Component features|
|org.eclipse.sphinx.examples||Examples (with source code)||All example features as per #Example features|
|org.eclipse.sphinx.testutils||Test utilities for JUnit-based integration tests running against a predefined reference workspace (with source code)|
|org.eclipse.sphinx.thirdparty||Required third-party components (selected Orbit plug-ins)|
Component features enable adopters to select and include individual Sphinx components in their applications. They are essentially a one-to-one representation of the architecture detailed above. Their IDs always include the name of the principal required Eclipse component that they are based on or extend. If necessary, they also indicate the name of the Sphinx component that they represent. The table below lists the component features that Sphinx offers for each of its components.
|Top-level service||Sub services||Feature|
|Navigator & Editor Sockets||Common Navigator Sockets||org.eclipse.sphinx.emf.navigators|
|Form Editor Sockets||org.eclipse.sphinx.emf.editors.forms|
|Nebula Extensions for Form Editors||org.eclipse.sphinx.emf.editors.forms.nebula|
|GMF Editor Sockets||org.eclipse.sphinx.gmf.editors|
|Validation Runtime Extensions||org.eclipse.sphinx.emf.validation|
|M2x IDE Integration||Xtend/Xpand IDE Integration||org.eclipse.sphinx.xtendxpand|
|Eclipse PDE Extensions||org.eclipse.sphinx.pde|
|EMF Runtime Extensions|
|Eclipse Platform Extensions|
Example features are auxiliary deliverables of Sphinx. They contain sets of example plug-ins demonstrating how adopters can use Sphinx capabilities and services in their applications. As such they are an important complement of Sphinx documentation (i.e., Sphinx Developer Guide, etc.). In addition to that, adopters may even want to include some of the examples features in their applications as is. The Sphinx Model Explorer or UML2 IDE Integration are typical candidates for such kind of features. The following example features are available: