Git repositories
The Eclipse ESCET project maintains the following source code repositories:
Main repository:
https://gitlab.eclipse.org/eclipse/escet/escet.gitWebsite repository:
https://gitlab.eclipse.org/eclipse/escet/escet-website.git
These can also be accessed via a web interface of the Eclipse Foundation GitLab:
New website versions are deployed from the build of the main repository. Changes should therefore be made to the main repository, rather than directly to the website repository. Since the website repository does not have its own issue tracker, issues for the website should be made on the main repository as well.
The software is written in the Java programming language, as a collection of Eclipse plugins, and using the Eclipse Modeling Framework (EMF).
For ease of programming, the Eclipse IDE is recommended. See also the section on setting up a development environment.
To contribute code (e.g. patches), documentation, or anything else, see the contributing section.
The way we work with our Git repository is explained as part of our development process.
Repository structure
In the Eclipse ESCET main source code repository (Git repository), three layers are distinguished:
The top layer contains user-oriented languages for designing controllers. Currently there are two modeling languages in this layer, CIF and Chi.
The third language in the top layer is ToolDef, a cross-platform scripting language to run tests, and to automate the various tools that need to be executed while designing a controller.
The middle layer contains developer oriented support code. It has a language of its own, named SeText. This language implements an LALR(1) parser generator with a few twists to make it easy to use in a Java environment and to connect it to an Eclipse text editor.
The other part of the middle layer is common functionality shared between the languages.
The bottom layer is mostly configuration to attach the software to the Eclipse platform, including build and release engineering.
This document describes the structure of the top and middle layers. For the bottom layer, standard Eclipse and Maven/Tycho tools are used, which are described elsewhere.
The three layers are not further distinguished in the repository. Instead, different parts are stored in different sub-directories from the root.
Language directories
Each language has its own subdirectory in the root, /cif and /chi for the CIF and Chi modeling languages, /tooldef for the ToolDef language, and /setext for the SeText language.
Within a language directory, a directory exists for each part of the code (often equivalent to a plugin), with the same name as the plugin. The pattern of a plugin name is org.eclipse.escet.<language>.<plugin-name> where the plugin-name in different directories has the same meaning. A non-exhaustive list:
| Plugin name | Description |
|---|---|
|
User-oriented documentation about the language, such as a user manual or a reference manual. |
|
Support libraries used by the documentation for generating figures. |
|
Ecore metamodel back bone of the language. Model classes for the central data structure that all tools of the language use. Often generated using modeling tools such as Sirius, but manually written classes exist as well. |
|
Generated Java constructor and walker classes for the Ecore metamodel data structure. |
|
SeText input, and generated or manually written code to parse an input file and convert it to an tree of classes that can be given to the type checker. |
|
Implementation of the type checker to check the parsed input, and annotate it with derived information, resulting in an model instance that can be used by all tools of the language. |
|
Text file loading, parsing, and type checking, and possibly writing result specifications. |
|
Code for editing source files of the language in an text Eclipse editor, with folding, syntax highlighting, and reporting of errors and warnings in the specification. |
|
Collection of tests to check the tools for the language. Typically a set of input specifications, a set of expected output files, and a ToolDef script to run the tests. These tests can be seen as integration tests. |
|
Code generator to convert the input specification to a runnable model. |
|
Support libraries used by the runnable model. |
|
Interface definitions to make tools of the language available for ToolDef. |
|
Common functionality used by many tools of the language. |
Other plugin names are often tools with the same name.
Middle layer common functionality
The common code between all languages is stored in the /common directory, again with full name of the plugin as sub-directory names. These plugins contain:
| Plugin name | Description |
|---|---|
|
Common application framework. |
|
The Applications view provides a user interface to manage the active applications. |
|
Common functionality related to AsciiDoc documentation. |
|
Library to generate formatted code-like text. |
|
Common Eclipse User Interface code. |
|
Common EMF code. |
|
Code generators from Ecore files. |
|
Common EMF validation code. |
|
Common EMF XMI serialization code. |
|
Common Java functions and classes, in particular the Lists, Sets, Maps and Strings classes. |
|
A pure Java implementation of Multi-value Decision Diagrams (MDDs). |
|
Common functions for (text-file) positions in source files. |
|
The Ecore metamodel for (text-file) positions in source files. |
|
Rail diagram generator. Produces syntax diagrams. |
|
Common SVG library for viewing and manipulating SVG trees. |
|
Common type checker functionality. |