The source code of the [GEMOC Studio](http://gemoc.org/studio/) is currently spread among different git repositories in Eclipse organization.
This project relies on the presence of the correct git repositories (cloned with the correct name) to locally build a working studio.
First checkout the git repositories :
git clone https://github.com/eclipse/gemoc-studio git clone https://github.com/eclipse/gemoc-studio-modeldebugging
Note: the repositories must keep their names (Ie. do not change the destination folder name) as the maven pom file expects to find them at specific locations.
Then compile using maven:
cd gemoc-studio/dev_support/full_compilation mvn package -Dmaven.repo.local=$PWD/localm2
We use one options:
-Dmaven.repo.local=$PWD/localm2: use a folder called localm2 to cache all the external dependencies of the studio, instead of using the user local maven repository. Since the GEMOC Studio a full eclipse package and has around 1GB of dependencies, this avoids using this much space in a hidden folder of the user home dir.
If you prefer to use your own local maven repository (ie. in <HOME>/.m2/repository), remove the use of -Dmaven.repo.local, ie. use this command:
mvn package
If you already compiled and resolved all dependencies at least once (ie. if you filled your local maven repository with everything
needed for the build), add the option -o to perform an offline only build, which is significantly faster since it skips checking all maven repositories online.
In the end, the result can be found in gemoc_studio/gemoc_studio/releng/org.eclipse.gemoc.gemoc_studio.product/target/products/, with one studio zip per platform.
The build also assemble complementary results:
- an update site, available in
gemoc_studio/gemoc_studio/releng/org.eclipse.gemoc.gemoc_studio.product/target/repository/ - an archivable version of the web help; available in
gemoc-studio/docs/org.eclipse.gemoc.studio.doc/target/publish/webhelp/
If you have trouble to reproduce a bug in the CI or want to make sure that the CI will pass, you can run the maven build in a docker that mimic the CI environment.
To do a full build using docker: go to the docker folder (/gemoc-studio/dev_support/full_compilation/docker), then call the command
docker-compose down && docker-compose up
Once the full compilation has been done at least once (ie. and filled the m2 cache), you can run the system test only using the command
docker-compose run gemoc_full_compilation system_test_only
Or you can run a full build but including only the linux variant using:
docker-compose run gemoc_full_compilation linux
or
docker-compose run gemoc_full_compilation linux_offline
The Dockerfile defines a docker image based on ubuntu 16.04 with maven, oracle java8, xvfb, and graphviz. It embeds an entrypoint.sh script that calls the maven command.
The docker-compose.yml will mount the folder containing all gemoc repositories (ie. the place where you’ve done git clone)
It also mounts a cache-m2 folder in order to speed up the compilation.
The docker-compose command is more or less equivalent to:
docker build -t gemoc-full-compilation . docker run -v $PWD/../../../..:/root/src -v $PWD/cache-m2:/root/.m2 gemoc-full-compilation
Then you’ll have to manually prune unused containers after usage.
If for some reason you wish to access it interactively you can use the following command:
docker run --entrypoint "/bin/bash" -ti -v $PWD/../../../..:/root/src -v $PWD/cache-m2:/root/.m2 gemoc-full-compilation
GEMOC addons mecanism is the simpliest way to contribute new features to GEMOC. Most of the features in GEMOC have been developed using it.
Basically, it uses Eclipse plugin extension point in order to provide additional feature to an existing engine.
The main extension point is org.eclipse.gemoc.gemoc_language_workbench.engine_addon which allows to declare a new class that implements the IEngineAddon interface.
Minimal steps to get an addons:
- Create a plugin project (or contribute to an existing one)
- In the MANIFEST.MF or plugin.xml editor, open the extensions tab, Add, uncheck "Show only extension from the required plugins", search for "gemoc" and select the
org.eclipse.gemoc.gemoc_language_workbench.engine_addonextension point, accept to add the dependency to the plugin. (see Figure 58, “New Extension for Engine Addon screenshot”) - add an addon entry in the extension point (see Figure 59, “EngineAddon extension point details screenshot”) provide a name and a description that will help the end user to know if she wish to enable the addon or not in the launch tab when configuring her model execution.
- Create the class implementing org.eclipse.gemoc.xdsmlframework.api.engine_addon.IEngineAddon (a click on Class*: in the extension editor allows to open a wizard that simplify this task)
- you can now override any of the default methods of the interface (cf. Figure 54, “Execution Framework API Interfaces overview”). If the user select the addon in the launch tab, these methods will be called by the engine.
Note
The calls from the engine to the methods of IEngineAddons block the model execution. Thus, except if this is the expected behavior, the addons should avoid to do complex/long running/blocking task directly in the
Note
For a given notification to IEngineAddon (for example aboutToExecuteStep), the order of calls to all registered addons is currently not ensured.
Help is welcome in order to implement a way to specify partial order between addons as it might be useful when several collaborating addons must react on the same notification.
Tip
In the extension declaration, setting Default to true will activate the addon by default when creating a new launch configuration. The user is still able to disable the addon manually.
Tip
See Section 3, “GEMOC framework” for more details about the extension point and other supported features.
Tip
An Engine addon may be generic and apply to any language, but it can also be language specific. In that case, you should prefer to add its code in the project containing the dsl file of the language and declare it in the plugin.xml.
This way, the addon will be available only for this specific language.
This can be useful in order to create language specific GUI (with input/output) and complex model animation. (see Section 3.2, “Define an animation representation using an engine addon”)
As seen in Figure 47, “Components overview”, the framework is organized in several layers. The most complete layer is the GEMOC Framework which offers most of the advanced features. Thus, implementing an engine for a new technology consist in 2 main parts:
- implementing subclasses for the classes from XDSML Framework in order to have the part dedicated to the Language Workbench,
- and implementing subclasses for the classes from Execution Framework in order to have the part dedicated to the Modeling Workbench
The GEMOC documentation (this document) structure is designed to:
- allow both online and eclipse help output,
- display an outline that helps organizing contributions,
- maintain the documentation sources as close as possible of the documented element in order to associate documentation commits to the code commits,
- use a rich but human readable syntax,
- ease modification.
As it supports include directives, we chose Asciidoc syntax with the appropriate tool chain.
Some of the diagrams are generated using plantuml.
The document is organized as follow:
- one master.asciidoc document that contains the main outline and use
includedirective in order to embed all the chapters and sections. (https://github.com/eclipse/gemoc-studio/tree/master/docs/org.eclipse.gemoc.studio.doc/src/main/asciidoc/master.asciidoc) -
included sections are spread across the repositories according to their content
- files named
* headContent.asciidocare headers of a chapter/section defined in master.asciidoc, the other files are contributions to a chapter/section. - sections related a specific user interface are located in a docs folder directly in the corresponding plugin. (ex: description of a wizard to be included in the user guide)
- sections related to a component are stored in a docs folder next to the plugins, tests and, releng folders (ex: sections for the Developer Guide)
- general sections are located in folders in https://github.com/eclipse/gemoc-studio/tree/master/docs/org.eclipse.gemoc.studio.doc/src/main/asciidoc/
- files named
-
one pom.xml which allows to build the whole document. (https://github.com/eclipse/gemoc-studio/tree/master/docs/org.eclipse.gemoc.studio.doc/pom.xml).
- It also takes care to generate the png images from the plantuml sources. To achieve this, it first copies all images folders from included sections.
Tip
In order to ease modifications, every files must start with a footnote allowing to retrieve the source file in the git repositories.
Tip
To edit the documentation we recommand the use of plantuml eclipse plugin and eclipse asciidoc editor . You can install them in an Eclipse using either the market place or the following update site: https://ascii-uml.github.io/eclipse/
[83] asciidoc source of this page: https://github.com/eclipse/gemoc-studio/tree/master/docs/org.eclipse.gemoc.studio.doc/src/main/asciidoc/dev/DevelopingNewAddons.asciidoc.
