Software Stack Guidelines

These guidelines describe, which technologies should be used for the project. There are 2 different software stacks in general: the primary stack provides the basis for the actual functionality and the secondary stack integrates the source code with the environment. The core stack represents the minimal software required to build and run this project. The extending stack extends the usefulness of the core stack and makes it more deployable.

By default, the core stack is more restricted as the extending one, because the second stack needs to be compatible with first one. Also, one wants the core stack to be compatible to as many extending stacks as possible, which makes the software more portable. This requirement does not exist the other way around by default.

Every software stack should be compatible to the  software project file system standards  by default.

The following software stacks are currently recommended:

Java and Maven are the main base technologies for the projects core functionality. These are also the preferred basis for any software part.

Shell (sh) is used to simply integrate software into the environment. In other words, shell scripts are used to call other programs.

At least Python 3.12 is used for complex software integration into the environment. In other words, Python 3 is used instead of shell, when otherwise somewhat complex logic would be done in shell scripts or argument parsing needs to be done.

It cannot be automatically ensured, that the Java and Maven version of a Linux distribution are as new as required (which was sometimes a problem in the past). This would cause issues especially at a time, when a new major Java is released. Therefore, Java and Maven are preferredly executed inside containers. At least Python 3.12 is used, because most Linux distribution provide such a Python version, regardless if the distro is a long term supported (LTS) one or not.

This is especially important, in order to easily support bootstrapping the software build across multiple servers, because executing such Python scripts without a container is always assumed to be easily possible. Such bootstrapping was not known to be easily possible via shell scripts and therefore Python was used to create the bootstrap tooling called Network Worker Execution (bin/worker.execute). Now it is known, that Java and shell could have been used for bootstrapping as well, even though it would be a bit more complex. If in the future the Worker Execution is needed for the Java services as well, in order to coordinate Java processes across servers, the Worker Execution should be ported to Java and the Python version of the Worker should be considered for deletion.

Keeping the size of the minimal technology stack as small as possible, is a goal of this project, in order to simplify development and deployment. If it where not for small, but a bit complex scripts, Python would have been removed from this project. Java provides a way to execute a single file source code program, as easily as Python, but Java's standard library does not provide a good library for shell argument parsing. Therefore, a parsing library is required, which makes such sing file source code programs harder to implement.