[WIP] Gradle & Kotlin Projekt Template

In modernen Softwareprojekten werden häufig Hilfsmittel eingesetzt um die Entwicklung zu erleichtern oder die Qualität zu erhöhen. Die Auswahl der Hilfsmittel kann dabei sehr schwer sein und viel Zeit in Anspruch nehmen. Um das zu erleichtern habe ich auf GitLab ein Template Projekt bereitgestellt in dem einige Best Practices verbaut sind und folgende Hilfsmittel verwendet werden:

  • Gradle mit Kotlin DSL
  • Kotlin
  • Docker
  • GitLab CI
  • Detekt
  • IntelliJ

Warum Gradle?

In den meisten Java Projekten wird Maven als Build Tool eingesetzt. Eine moderne alternative dazu ist Gradle, das immer häufiger (z.B. als Standard bei der Android Entwicklung) verwendet wird und einige interessante Features wie z.B. Inkrementelle Builds, Build Cache, Gradle Daemon und Build Scans. Das macht Builds schneller, besser wart und nachvollziehbar als z.B. mit Maven. Mehr zu den Unterschieden zwischen Gradle und Maven kann man hier lesen.

Durch die Kotlin DSL erhält man in eine gute IDE Unterstützung mit unter Anderem autocompletion, refactoring und documentation.

Warum Kotlin?

Data Class, Null Safety, Default Parameter, String Interpolation, ….. !

Warum GitLab (CI)?

Kostenlose private Repositories mit (kostenloser) CI und Runnern. Für das schnelle aufsetzten eines privaten Projekts daher super geeignet. In größeren kommerziellen Projekten reicht das kostenlose Angebot von GitLab unter umständen nicht mehr aus, allerdings sind die Preise auch im kostenpflichtigen Bereich moderat. Außerdem bietet GitLab viele nützliche Funktionen wie Issue Board oder Kubernetes Integration.

Gradle

Zeile 5 - 12

Zu Beginn werden generelle Informationen zum Projekt angegeben, wie Group Name, Version und die Java Version. Das Equivalent zur aus Maven bekannten „artifactId“ ist bei Gradle der „rootProject.name“ ind wird in der settings.gradle.kts definiert. Die Version soll sich niemals ändern, da unser Deployment Artefakt nicht die Jar Datei ist, sondern der Docker Container, der wiederum eine Version haben wird.

Zeile 14 - 32

In Zeile 18 – 32 werden die verwendeten Plugins aktiviert. Das Plugin „application“ erstellt eine standard Applikation mit allem was benötigt wird um sie unter Linux und Windows auszuführen. In Zeile 14 – 16 wird die zu nutzende Main definiert. Mit dem Befehl „gradle assemble“ werden .bat und .sh Dateien zum Ausführen erstellt (in build/scripts) und die Applikation in ein .zip und .tar Archiv gepackt (in build/distribution). Mehr dazu kann man in der Dokumentation finden.

Das Plugin „kotlin“ sorgt für die Unterstützung der Programmiersprache und durch den angegebenen Parameter „jvm“ wird auf der JVM lauffähiger Code generiert. An der Stelle ist es z.B. auch möglich Javascript zu genereieren.

Außerdem werden die Plugins detekt und build-scan aktiviert, die später noch weiter beschrieben werden.

Zeile 36 - 40

Fail fast bei Versions-Konflikten von Dependencies. Das betrift auch Versionen von transitiven Dependencies. 

Zeile 43 - 49

Hier werden Kotlin Options gesetzt, die bei der Compilation zu Java angewendet werden. Mit „-Xjsr305=strict“ werden Nullability-Probleme nicht nur als Warnungen angezeigt, sondern in Errors umgewandelt. „jvmTarget“ legt die Zielversion des generierten Bytecodes fest und mit „allWarningsAsErrors“ werden alle Warnungen als Errors ausgegeben… wer hätte es gedacht 😅 Mehr kann man hier darüber lesen.

Zeile 52 - 54

Das generierte Jar File soll den Namen „app.jar“ haben. Das vereinfacht die Erstellung des Docker images, da man genau diese Datei und nicht eine Wildcard wie z.B. *.jar zum kopieren in das Image verwenden kann. Die Version brauchen wir aus oben genannten Gründen nicht.

Zeile 57 - 71

An dieser Stelle wird JUnit konfiguriert. Mit useJUnitPlatform wird Gradle gesagt, dass JUnit verwendet werden soll. In testLogging werden ausführlichere Log-Meldungen eingestellt.

Zeile 73 - 77

Einer der interessanteren Punkte ist der Build Scan. Diese Funktionalität wird von Gradle bereitgestellt und ermöglicht es unter Anderem die verwendeten Parameter, Umgebungsdetails und die Luafzeit eines Builds auf einer Website anzusehen. Mehr dazu kann man hier erfahren.

Zeile 73 - 795

In diesem Bereich werden die benötigten Dependencies und Repositories angegeben. Dabei kann mithilfe der configuration wie z.B. „testCompile“ der Scope der Dependency festgelegt werden. Gradle bietet hier eine Auflistung und Erklärung der wichtigsten configurations.

Der Gradle Wrapper

In diesem Projekt ist es vorgesehen Gradle mithilfe des Gradle-Wrappers auszuführen. Dafür stehen im root Verzeichnis die Dateien gradlew(.sh) und gradlew.bat zur Verfügung. Beide Dateien kann man je nach Betriebssystem ausführen. Sie laden (wenn noch nicht geschehen) eine Gradle Version, die in der Datei gradle/wrapper/gradle-wrapper.properties definiert ist in den Ordner .gradle herunter und führen diese Version dann aus.

To be continued .......

Das Template ist auf GitLab zu finden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.