\label{doc_decisions_6_implemented_gradle_md_md_doc_decisions_6_implemented_gradle}%
\Hypertarget{doc_decisions_6_implemented_gradle_md_md_doc_decisions_6_implemented_gradle}%
 \hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2387}{}\doxysection{Problem}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2387}
Originally, Maven was used as the build system for Elektra\textquotesingle{}s Java-\/related modules. When it came time to modernize and improve Elekta\textquotesingle{}s Java bindings, the question of which build system to use had to be answered.\hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2388}{}\doxysection{Constraints}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2388}

\begin{DoxyItemize}
\item Existing dependencies must be supported by the chosen build system.
\item An established system with a supportive community would be of great advantage.
\item Build performance should not be negatively impacted.
\item Integration with existing build infrastructure is no more complicated than before.
\item The benefits of the transition outweigh the potential costs, making it a worthwhile investment.
\item Ease of use, community support, and flexibility were the most important factors to consider.
\item The fact that Maven does not provide native support for Kotlin, which is becoming increasingly popular with developers, was also an important factor to consider.
\end{DoxyItemize}\hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2389}{}\doxysection{Assumptions}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2389}
The development team either has the necessary expertise and resources for a successful transition, including knowledge of the new build system and familiarity with its syntax and conventions, or the new build system should be easy and intuitive for the development team to use, especially if the team is not already familiar with the new system.\hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2390}{}\doxysection{Considered Alternatives}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2390}

\begin{DoxyItemize}
\item Ant is a popular build tool that uses XML files to define build processes. It is flexible and can be used for a variety of languages, but it can be more verbose and less user-\/friendly than other build tools.
\item CMake is a build tool, which only has limited support for Java. It is popular for C/\+C++ projects and can be extensively customized, but it can be more difficult to use than other build tools and is not as flexible for projects that use multiple languages. Since Elektra is a C-\/based software project, this system would have had the advantage of already being in use.
\end{DoxyItemize}\hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2391}{}\doxysection{Decision}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2391}
We are switching from Maven to Gradle.


\begin{DoxyItemize}
\item Gradle is more flexible and customizable than Maven. It uses a Groovy-\/based DSL that allows developers to write custom plugins and scripts easily, making it easier to configure and automate complex build processes.
\item Gradle is faster than Maven. It offers more efficient incremental builds, meaning it can quickly determine which parts of the codebase have changed and only rebuild those parts. This might not yet bring a great improvement but allows for future scalability.
\item Gradle\textquotesingle{}s dependency management system is more flexible and offers more advanced features than Maven, including the ability to manage transitive dependencies and exclude specific unwanted dependencies. It also supports the same dependency eco-\/system as Maven does.
\item Gradle natively supports Kotlin.
\item Gradle offers an easy migration path from Maven.
\end{DoxyItemize}\hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2392}{}\doxysection{Rationale}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2392}
Gradle is not only the modern alternative to Maven, using the same dependency management infrastructure, but also opens up new possibilities for the growth of Elektra\textquotesingle{}s Java bindings and other Java-\/based language bindings.\hypertarget{doc_decisions_6_implemented_gradle_md_autotoc_md2393}{}\doxysection{Implications}\label{doc_decisions_6_implemented_gradle_md_autotoc_md2393}

\begin{DoxyItemize}
\item Changed the setup for building Java bindings to use Gradle instead of Maven.
\item The build images needed to be modified to create the necessary dependencies for integrating the Java bindings using Gradle instead of Maven.
\item Assets created will be transferred to Sonatype\textquotesingle{}s repository so developers can use the dependency framework used by Gradle (and Maven).
\item Developers need to switch to using Gradle.
\item Leverage Gradle\textquotesingle{}s caching capabilities to improve the performance of CI (continuous integration) builds. Gradle has several levels of cache. The global cache, which is shared by all projects built with Gradle on a given machine, stores artifacts such as JAR files and metadata downloaded from remote repositories and is used automatically. Using the local build cache is not beneficial for CI tasks. Depending on the actual build performance and whether it needs to be improved, configuring the remote build cache may be useful. It can be used to store the output of specific tasks or the entire build cache. Remote build caching can help speed up builds by reusing artifacts from previous builds, especially when building large projects with many dependencies -\/ which is not currently the case with Elektra. 
\end{DoxyItemize}