Gradle: Gezippte Dependency verwenden

via, und/bzw.

Darauf zugreifen kann man dann bspw. in anderen Tasks mittels

PS: Mir ist bewusst, dass ${buildDir} deprecated ist, aber ${layout.buildDirectory} ging aus irgendeinem Grund nicht.

Gradle: Task mit bestimmtem JRE ausführen

Edit zur Erklärung: Gradle benötigt Java, und bspw. ein installiertes JDK 17 kann natürlich Language Level 8 kompilieren. Aber es ist trotzdem ein JDK 17 und enthält bspw. kein JAXB mehr. Die Aufgabe ist hier, einen Gradle-Task unabhängig von meiner Java Version mit einem 8er JRE auszuführen. Das verwendete Plugin lädt alles dafür benötigte herunter.

Original Post below:

settings.gradle:

build.gradle:

via, und, Danke Nils!

IntelliJ: Gradle task mit jedem Reimport ausführen

IntelliJ bietet per Rechtsklick die Möglichkeit, Trigger für Tasks anzuhaken (Screenshot aus der Doku geklaut):

Via build.gradle kann man das über das Plugin “gradle-idea-ext-plugin” automatisieren – im Rootprojekt:

Und im Unterprojekt dann:

Achtung, in DSL spec v. 0.2 heißt es

  • beforeSync – before each Gradle project sync. Will NOT be executed on initial import

ka, aber spätestens danach funktioniert es.

Gradle: Replace in Copy task

Eine Ersetzung:

Mehrere Ersetzungen:

via

Gradle: Include/exclude tests

Exclude set of tests (via) and/or categories:

Pass collection from shell (via, and):

Run single test only (via):

Exclude all tests from build task:

to be completed

Gradle: ordered dependsOn

Statt

besser:

Postgres direkt aus Gradle

im Wesentlichen von hier.

Gradle: Extra properties extensions in buildscript

Extra Properties Extensions sind für globale Properties; mir würde spontan bspw. einfallen, die eine Versionsnummer für meine drölf Spring-Dependencies so zu zentralisieren.

Aber, Folgendes geht nicht:

, weil buildscript vor allem anderen ausgewertet wird. Aber so geht’s:

Achtung: Bei mir ging das ausschließlich in geschweiften Klammern und Quotes.

via

IntelliJ/Gradle/Groovy: “Conflicting module versions.”

, bei Ausführen des Tests aus IntelliJ heraus; per Kommandozeile geht’s.

Internet sagt, man müsse die Dependency excluden (lokal oder global), um Sie dann in nur der gewünschten Version wieder zu includen, aber das führte bei mir bestenfalls nicht zum Erfolg, und schlimmstenfalls zu

Error:Cannot compile Groovy files: no Groovy library is defined for module ‘my-module_test’

Internet sagt weiterhin, man könne eine bestimme Version forcieren, aber das hat bei mir genau gar keine Auswirkungen.

Geholfen hat dann, das Setup aus compile und testCompile zu überprüfen: Ich hatte ein Modul mit Test-Sourcen als compile project, die Dependency  org.codehaus.groovy:groovy-all:2.4.10 aber als test-compile eingebunden. Korrekt ist in dem Fall, das Modul als testCompile project einzubinden (oder alternativ die Dependency als compile, aber hier wäre das “falsch rum”).

Offenbar gilt von der Shell aus die höhere (oder die später deklarierte?) (transitive) Dependency, in IntelliJ aber die zuerst deklarierte.