...

As ready-made resulting packages, it is planned to make only completely independent parts of Apache Ignite. At the moment only Ignite core part and Ignite CLI can work as standalone applications and these applications should be distributed as OS-specific packages for all supported platforms. (Linux, Windows, MacOs). However, we will publish not only compiled packages, but there is also a need to publish individual parts of Apache Ignite that are not standalone applications, and we need to provide the user with the access to these parts. The prime candidate for this is the ignite-client with all its subparts (JDBC, SQL Api, etc Api). More about this will be described in paragraph Publishing.

...

ignite3-db

This package provides an the ability to run nodes on the local server. It includes:

...

Each package should be published and available to install for all supported platforms by in the native OS way. It means that the installation process should respect all UX of each OS :

1. We should provide the possibility to install each component with the default package manager (apt-get, yum, brew, etc.) of the OS.
2. Install, upgrade, update, and uninstall process should require all rules of OS guidelines. For example, remove all temp files after uninstall and not change these files in the upgrade process.

It is also necessary to support the publication of compiled images as zip files for the possibility of installation on those platforms where there are no package managers. For each supported architecture, it is necessary to build and publish a zip file with everything necessary for the application to fully work (except for the third-party dependencies, which should be installed as additional packages, but this list should be attached to the REQUIRED.txt file).

...

Code examples should be moved to a separate Git repository and also provided as a separate ZIP download for every release.

Examples are NOT included in any of the packages described above.

TDB

Gradle

In the context of packaging work, it would be useful to rewrite Apache Ignite to a Gradle build system. This work should be done before all packaging staff, we also need to verify that the build process is correctly working as previously. Also need to adapt all CI scripts for the new build system and scripts.

These several point points about what can be improved by Gradle using:

1. Various Gradle plugins that can make the build process easier. Rpm/Deb, brew, SDKMan, Docker, etc.
2. Currently, the Apache Ignite project contains many different validation scripts that need to be run manually or in TeamCity's automation scripts. Instead of all this, it can be unified in the gradle Gradle build scripts in order to be able to locally fully reproduce the build with CI.
3. Since we have 3 different packaging targets (ignite3-db, ignite3-cli, ignite3) all packaging logic can be unified in 1 gradle Gradle script and just used in target modules.

...

NOTE: All formats and running options MUST provide the possibility to run multiple instances of the ignite3-db module.

Zip archive

...

1. Download the zip file
2. Cd into the folder with the previous version
3. Run upgrade executable and provide the zip file as an argument

Also, the standard approach where we have /opt/ignite folder with ignite versions and /opt/ignite/latest as a symlink to current currently used versions. Upgrading will require downloading archive, unzipping it to /opt/ignite/<version>, making new symlink to /opt/ignite/latest

Upgrade The upgrade process should not remove data files.

Zip archive can be built with a gradle Gradle plugin.

RPM/DEB packages

The package includes:

...

1. Download RPM/DEB package
2. Run rpm -i <package> / apt install <path-to-deb> / dpkg -i <package>
3. After installation, the executable is represented as a system service (service file) and can be run with the system ignite start command. 

...

Apache Ignite should have a an RPM/Deb repository with all builded built packages. 

This is a common approach in the Linux community and is the standard way to install an application on a system.

1. User add the custom repository 
1. yum install https://yum-rep-address/repo-info.rpm
2. add-apt-repository http://repo-address 
2. Install required package
1. yum install ignite3 
2. apt install ignite3 

NOTE: Also in the future, it is necessary to consider the possibility of adding our packages to the standard repositories of common distributions.

...

Homebrew uses Formula to install the software. Formula is a Ruby class that describes the installation process. Formula should be placed in on GitHub and have a link to the zip archive.

There is also a way to create Formula via a gradle Gradle plugin https://github.com/jreleaser/jreleaser

Installation:

1. Add a custom github GitHub repo to the brew: brew tap apache/ignite-3 
2. Run brew install <package> 
3. After installation, the executable is represented as a command line app (ignite (CLI), ignite3-db (start, stop, restart))

...

A lot of product publishing in SDKMan javaJava, kotlinKotlin, scalaScala, mavenMaven, gradleGradle, sbt, Scala CLI, Quarkus CLI, Apache ActiveMQ, Flink, Spark, etc.

...

List: 

   sdk list ignite3 

Publishing The publishing process is described here and it's not much different from other package managers.

...

Docker

For the ignite3-db module, we also should build a Docker image which that can be used for easy Apache Ignite startup.

This image should contain ready-for-use Apache Ignite with all required dependencies. After the image is created Apache Ignite should be started and ready for use. By default, all ports of Ignite server should be forwarded as is and no additional changes are required.

Also, https://jreleaser.org/guide/latest/configuration/packagers/docker.html can simplify the process of docker image building.

...

As you can see https://github.com/jreleaser/jreleaser can help us with publishing setup infrastructure and cover all cases. This is a good reason to try to use it as the only required dependency to unify how different packages are built.

Also, https://jreleaser.org/guide/latest/examples/micronaut-cli-app.html provides native support of for the Micronaut CLI project which is Apache Ignite CLI.

Risks and Assumptions

TDB

...

Mostly, there are no risks.The main critical part of the changes is the transition of the build process to Gradle.This moment should be separately tested, and the transfer of CI to a new build system should be made after a complete ready-check of the build gradle.

Discussion Links

TDB

Tickets