Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Sphinx/architecture"

(→‎Architecture)
Line 1: Line 1:
−
Sphinx heavily uses and extends other Eclipse (modeling) components. Adopters may not require all of those in their applications or even might be constraint to not using some of them. Sphinx is therefore based on an architecture that makes the dependencies wrt to required Eclipse components transparent. At the same time, it delivers the structure for the features which group the Sphinx plug-ins physically together and make it happen that the individual parts of Sphinx to be used independently of each other.
+
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 to required Eclipse components transparent and keeps them separated as much as possible. This architecture is also the basis for the structure of the features in which Sphinx plug-ins are delivered. Together, they make it happen that the individual parts of Sphinx to be used independently of each other.
−
 
+
−
The following sections are dedicated to providing the details about this architecture and feature structure.
+
  
 
= Architecture =
 
= Architecture =
Line 28: Line 26:
  
 
= Feature Structure =
 
= Feature Structure =
 +
 +
The structure of Sphinx features is basically a one-to-one representation of the architecture detailed above. For each component, Sphinx provides a set of features that contain the different pieces of a component, i.e., runtime, sources, documentation, examples, etc. Component features are hierarchically bundled up in container and root features. Adopters can freely choose which of these features they want to refer to and thus have full control over the Sphinx components and pieces that get included in their applications. 
  
 
== Conventions ==
 
== Conventions ==
  
−
''ToDo: Say something about content of following table and naming template.''
+
The following table lists the different pieces of a Sphinx component along with a short description of their content and the name pattern for the corresponding features. The idea behind the name pattern is that feature names are supposed to always include the name of the Sphinx component that they represent and optionally indicate the principal required Eclipse component that they are based on or extend.
  
 
{|cellpadding="5" cellspacing="0" border="1"
 
{|cellpadding="5" cellspacing="0" border="1"
 
!Feature type
 
!Feature type
 
!Description
 
!Description
−
!Naming template
+
!Name pattern
 
|-
 
|-
 
|Runtime
 
|Runtime
 
|Binaries without source code
 
|Binaries without source code
−
|org.eclipse.sphinx.<componentName>(.<technologyName>)
+
|org.eclipse.sphinx.<componentName>[.<requiredComponentName>]
 
|-
 
|-
 
|Sources
 
|Sources
 
|Source code for runtime binaries
 
|Source code for runtime binaries
−
|org.eclipse.sphinx.<componentName>(.<technologyName>).source
+
|org.eclipse.sphinx.<componentName>[.<requiredComponentName>].source
 
|-
 
|-
 
|Documentation
 
|Documentation
 
|Help content (Developer Guide, etc.)
 
|Help content (Developer Guide, etc.)
−
|org.eclipse.sphinx.<componentName>(.<technologyName>).doc
+
|org.eclipse.sphinx.<componentName>[.<requiredComponentName>].doc
 
|-
 
|-
 
|SDK
 
|SDK
 
|Runtime + sources + documentation (but not examples)
 
|Runtime + sources + documentation (but not examples)
−
|org.eclipse.sphinx.<componentName>(.<technologyName>).sdk
+
|org.eclipse.sphinx.<componentName>[.<requiredComponentName>].sdk
 
|-
 
|-
 
|Examples
 
|Examples
 
|Example plug-ins including sources
 
|Example plug-ins including sources
−
|org.eclipse.sphinx.<componentName>(.<technologyName>).examples
+
|org.eclipse.sphinx.<componentName>[.<requiredComponentName>].examples
 
|-
 
|-
 
|Test Utilities
 
|Test Utilities
 
|Utilities and support for JUnit-based unit and integration tests
 
|Utilities and support for JUnit-based unit and integration tests
−
|org.eclipse.sphinx.<componentName>(.<technologyName>).testutils
+
|org.eclipse.sphinx.<componentName>[.<requiredComponentName>].testutils
 
|}
 
|}
  
−
Note: All components do not necessarily provide all of above mentioned feature types.
+
Note: All components do not necessarily have to provide all of above mentioned feature types.
  
−
== Top-level features ==
+
== Root features ==
  
−
The top-level features are the primary deliverables of Sphinx and can be used to pull all other Sphinx features and the plug-ins. They are also subdivided and named according to the conventions provided above:
+
The root features are the primary deliverables of Sphinx and can be used to pull all Sphinx components at once. The following root features are provided:
  
 
* org.eclipse.sphinx
 
* org.eclipse.sphinx
Line 74: Line 74:
 
* org.eclipse.sphinx.testutils
 
* org.eclipse.sphinx.testutils
  
−
== Component features (layers and slices) ==
+
== Component features ==
  
−
The structure of Sphinx component features is basically a one-to-one representation of the architecture detailed above.
+
The table below lists the component features offered by Sphinx. They enable individual Sphinx components to be selected and included in applications. For the sake of keeping things easier to oversee, only the runtime features are indicated.
  
−
* Core components:
 
−
** Eclipse Platform Extensions
 
−
** EMF Runtime Extensions
 
−
** Workspace Management
 
  
−
* Vertial components:
+
Vertikal components:
 
** Navigator & Editor Sockets
 
** Navigator & Editor Sockets
−
*** Common Navigator Explorer Support
+
***
 
*** Form Editor Socket
 
*** Form Editor Socket
−
*** GMF Editor Socket
+
***  
−
*** Graphiti Editor Socket
+
 
−
** Validation Runtime Extensions
+
 
−
** Compare & Merge Integration
+
 
−
** M2x Integration
+
{|cellpadding="5" cellspacing="0" border="1"
−
*** Xtend/Xpand Integration
+
!Component
 +
!Features
 +
|-
 +
|
 +
|
 +
|-
 +
|
 +
|
 +
|-
 +
|Common Navigator Explorer Support
 +
|
 +
|-
 +
|Form Editor Socket
 +
|
 +
|-
 +
|GMF Editor Socket
 +
|
 +
|-
 +
|Graphiti Editor Socket
 +
|
 +
|-
 +
|Validation Runtime Extensions
 +
|
 +
|-
 +
|Compare & Merge Integration
 +
|
 +
* org.eclipse.sphinx.emf.compare
 +
* org.eclipse.sphinx.emf.compare.team.subversive
 +
|-
 +
|Xtend/Xpand Integration
 +
|org.eclipse.sphinx.m2x.xtendxpand
 +
|-
 +
|Workspace Management
 +
|org.eclipse.sphinx.emf.workspace
 +
|-
 +
|EMF Runtime Extensions
 +
|org.eclipse.sphinx.emf
 +
|-
 +
|Eclipse Platform Extensions
 +
|org.eclipse.sphinx.platform
 +
|}

Revision as of 11:37, 28 June 2011

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 to required Eclipse components transparent and keeps them separated as much as possible. This architecture is also the basis for the structure of the features in which Sphinx plug-ins are delivered. Together, they make it happen that the individual parts of Sphinx to be used independently of each other.

Architecture

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

SphinxArchitecture.png

Dependencies

The following table lists the dependencies of Sphinx components wrt existing Eclipse (modeling) components. Only directly required Eclipse components are listed (but not the Eclipse components being required by the directly required Eclipse components).

Component Dependencies
Core
  • Eclipse Platform
  • EMF
  • EMF Transaction
T.b.c. ...

Feature Structure

The structure of Sphinx features is basically a one-to-one representation of the architecture detailed above. For each component, Sphinx provides a set of features that contain the different pieces of a component, i.e., runtime, sources, documentation, examples, etc. Component features are hierarchically bundled up in container and root features. Adopters can freely choose which of these features they want to refer to and thus have full control over the Sphinx components and pieces that get included in their applications.

Conventions

The following table lists the different pieces of a Sphinx component along with a short description of their content and the name pattern for the corresponding features. The idea behind the name pattern is that feature names are supposed to always include the name of the Sphinx component that they represent and optionally indicate the principal required Eclipse component that they are based on or extend.

Feature type Description Name pattern
Runtime Binaries without source code org.eclipse.sphinx.<componentName>[.<requiredComponentName>]
Sources Source code for runtime binaries org.eclipse.sphinx.<componentName>[.<requiredComponentName>].source
Documentation Help content (Developer Guide, etc.) org.eclipse.sphinx.<componentName>[.<requiredComponentName>].doc
SDK Runtime + sources + documentation (but not examples) org.eclipse.sphinx.<componentName>[.<requiredComponentName>].sdk
Examples Example plug-ins including sources org.eclipse.sphinx.<componentName>[.<requiredComponentName>].examples
Test Utilities Utilities and support for JUnit-based unit and integration tests org.eclipse.sphinx.<componentName>[.<requiredComponentName>].testutils

Note: All components do not necessarily have to provide all of above mentioned feature types.

Root features

The root features are the primary deliverables of Sphinx and can be used to pull all Sphinx components at once. The following root features are provided:

  • org.eclipse.sphinx
  • org.eclipse.sphinx.sdk
  • org.eclipse.sphinx.examples
  • org.eclipse.sphinx.testutils

Component features

The table below lists the component features offered by Sphinx. They enable individual Sphinx components to be selected and included in applications. For the sake of keeping things easier to oversee, only the runtime features are indicated.


Vertikal components:

    • Navigator & Editor Sockets
      • Form Editor Socket


Component Features
Common Navigator Explorer Support
Form Editor Socket
GMF Editor Socket
Graphiti Editor Socket
Validation Runtime Extensions
Compare & Merge Integration
  • org.eclipse.sphinx.emf.compare
  • org.eclipse.sphinx.emf.compare.team.subversive
Xtend/Xpand Integration org.eclipse.sphinx.m2x.xtendxpand
Workspace Management org.eclipse.sphinx.emf.workspace
EMF Runtime Extensions org.eclipse.sphinx.emf
Eclipse Platform Extensions org.eclipse.sphinx.platform
Retrieved from "https://wiki.eclipse.org/index.php?title=Sphinx/architecture&oldid=259060"

Back to the top