There are three ways to produce GAMA from its sources:

1. a local release for your own platform, built from Eclipse with the GAMA Developer Tools;
2. a command-line Maven build, which produces the archives for all supported platforms;
3. the official releases and pre-releases, built, signed and published by GitHub Actions.

With the GAMA Developer Tools installed and the core plugins imported, choose GAMA > Run GAMA > Build local release... (also available as an icon of the GAMA toolbar).

1. Choose an existing destination directory outside the checkout (the previous one is remembered). The checkout is the one containing the workspace's gama.parent project. Eclipse asks to save the modified editors: the build uses the files saved on disk, including uncommitted changes. It does not fetch, switch branches or modify the checkout.
2. Follow the GAMA Local Release console and the Progress view. Cancelling stops Maven and its subprocesses. The first build is long and needs disk space (source snapshot, Maven dependencies, build outputs and the final product with its JDK).
3. On success, a dialog says GAMA produced in [folder] and offers Close or Run.

What the build does:

• It uses Eclipse's Java runtime if it is a full JDK 25, otherwise the first compatible JDK 25 of Preferences > Java > Installed JREs. This JDK is copied into the release, so the result does not depend on Eclipse or on the original JDK installation.
• Apache Maven is downloaded on first use (checksum verified) and managed privately: no system Maven is required. Internet access is needed for this download and for uncached Maven/p2 dependencies.
• The sources are snapshotted, then gama.annotations, gama.processor and gama.parent are built in this order, as in the official build. Only the modules of the gama.parent reactor and the bundles of features reachable from the GUI product are included: use Add to GAMA build... (GAMA context menu of a plugin) to include a new plugin. The optional Copilot feature is left out, as in the official build script.
• Only the current OS and architecture are built (macOS Intel / Apple Silicon, Windows x86-64 or Linux x86-64). Tests, signing, deployment and version bumping are disabled.

The result is Gama.app on macOS, or a Gama folder containing the launcher (Gama.exe or Gama) on Windows and Linux, with build.log and launch.log inside. Existing releases are never overwritten. This is an unsigned local build: macOS may require explicitly allowing the application.

See the tools guide for all the details.

Requirements: a clone of the repository, Maven 3.9 and a JDK 25. Set JAVA_HOME to the JDK 25 and check that mvn -version reports Java 25. From the root of the repository, build the two prerequisite projects, then the parent:

mvn -f gama.annotations/pom.xml clean install
mvn -f gama.processor/pom.xml clean install
mvn -f gama.parent/pom.xml clean install

The script travis/build.sh runs the same three steps (additional arguments are passed to Maven). It is the one used by the CI; note that it is written for Linux runners and removes the optional gama.feature.copilot from gama.product/gama.product before building.

The results are in gama.product/target/products:

• gama.ui.application.product/ and gama.headless.product/: the materialized products, one folder per platform;
• gama.application-<os>.<ws>.<arch> and gama.headless-<os>.<ws>.<arch> archives (.zip or .tar.gz, depending on the platform; Linux uses .tar.gz), for macosx.cocoa.x86_64, macosx.cocoa.aarch64, win32.win32.x86_64 and linux.gtk.x86_64.

These archives do not contain a JDK and are not signed.

Releases are produced by the GitHub Actions workflows of .github/workflows, using the scripts of the travis folder (the historical name has been kept; Travis CI itself is no longer used).

A release is created by running the workflow "Create & Publish new GAMA release" (trigger-gama-release.yaml) manually from the Actions tab. Its inputs are:

A pre-release can also be requested by pushing a commit whose message contains ci release: the validation workflow then dispatches the release workflow on that branch with IS_STABLE_RELEASE=false and the tag <current year>.<current month>.0, the other inputs keeping their default values.

flowchart LR
    A[Compile<br/>travis-build.yaml] --> C[Embed JDK<br/>travis-packaging-jdk.yaml]
    B[Prepare scripts<br/>bumpGamaVersion.sh] --> C
    C --> L[Linux .deb]
    C --> W[Windows installer]
    C --> M[macOS signed &<br/>notarized .dmg]
    A --> T[Tests]
    L & W & M --> G[GitHub release<br/>travis-publish-github.yaml]
    G --> X[Winget / Docker /<br/>PPA / prism-gaml]
    A --> P[p2 update site]

The main steps are:

1. Versioning. travis/bumpGamaVersion.sh sets the version of all the bundles, features and products with the Tycho versions plugin (<tag> for a stable release, <tag>-SNAPSHOT for a pre-release), updates the copyright year of the Java headers, the installers' metadata and the build information (version, commit, branch, date, JDK) stored in gama.product/gama.product. For a stable release, the product and the p2 site are also pointed to the versioned update repository. These changes are made in the CI runner only; nothing is committed back.
2. Compilation and signing of the JARs (travis-build.yaml). The GAMA keystore is decoded from the repository secrets and a sign.maven file activates the JAR-signing profile; travis/build.sh then builds all the platforms. For public GitHub releases, the development logging/debug flags of the products are disabled.
3. p2 update site. travis/deploy-p2.sh builds gama.p2site and uploads it to the GAMA update server (/var/www/gama_updates/...). This happens for every release, alpha or stable.
4. Packaging (travis-packaging*.yaml). The archives are converted to zip files and, with travis/zip_withjdk.sh, a "with JDK" variant embedding the requested Temurin JDK (downloaded from Adoptium and checked against its SHA-256) is produced. Then:
   • Linux: .deb packages gama-platform and gama-platform-jdk;
   • Windows: installers built with Inno Setup (windows_installer_script.iss);
   • macOS: for Intel and Apple Silicon, with and without JDK, the application is signed with the Developer ID certificate (travis/mac-sign.sh, what2sign.sh, entitlements.plist, hardened runtime), packaged as a .dmg, notarized with notarytool and stapled.
   • Unless skipTests is set, the built GAMA and the Linux and macOS packages are tested.
5. Publication on GitHub (travis-publish-github.yaml, if releaseGithub is checked). travis/publish-github.sh renames the files as GAMA_<version>_<Windows|Linux|MacOS_Intel|MacOS_Silicon>[_with_JDK] (.exe, .zip, .deb, .dmg); pre-release names are suffixed with the build date and the short commit hash. A checksum.txt file (SHA1, SHA256, SHA512, MD5) is added. Any previous release with the same tag is deleted and the tag is (re)created on the built commit. A pre-release is published as Alpha Version <tag> (marked as pre-release); a stable release as Version <tag>, marked as the latest release. Release notes are generated by GitHub.
6. Third parties (travis-publish-third-party.yaml, after the GitHub publication, each one optional): Winget (GamaPlatform.Gama, or GamaPlatform.GamaAlpha for pre-releases), a Docker image (by triggering gama.docker), the Debian/Ubuntu repository (by triggering gama.ppa), and a new version of the prism-gaml syntax-highlighting package.

The signing keys, certificates, notarization credentials, server credentials and bot token are stored as secrets of the repository: only maintainers can run the release workflow.