Japanische Übersetzung von Kapitel 47. Java-Schnellstart auf der offiziellen Gradle-Seite.
Chapter 47. Java Quickstart
Wie wir gesehen haben, ist Gradle ein generisches Build-Tool. Fast alles, was der Benutzer implementieren möchte, kann mit einem Build-Skript erstellt werden. Um den Build auszuführen, müssen Sie dem Build-Skript jedoch Code hinzufügen.
Die meisten Java-Projekte sind grundsätzlich ähnlich. Kompilieren Sie Java-Quelldateien, führen Sie Unit-Tests durch, Sie müssen eine JAR-Datei erstellen, die die Klassen enthält. Wenn Sie den obigen Prozess nicht mehr in allen Projekten codieren müssen Das wäre nett. Glücklicherweise müssen Gradle-Benutzer den obigen Prozess nicht codieren. Gradle löst dieses Problem mithilfe eines Plug-Ins. Plugins werden erweitert, damit Sie Ihr Projekt auf irgendeine Weise konfigurieren können. Fügen Sie nützliche voreingestellte Aufgaben hinzu. Gradle wird mit einer Reihe von Plug-Ins geliefert Sie können es ganz einfach selbst erstellen und mit anderen teilen. Ein solches Plug-In ist das Java-Plug-In. Dieses Plug-In kompiliert den Java-Quellcode des Projekts, führt Unit-Tests aus und Fügen Sie einige Aufgaben hinzu, um eine JAR-Datei zu generieren.
Java-Plug-Ins basieren auf Konventionen. Das Plug-In ist der Speicherort der Java-Quelldatei usw. Definiert Standardwerte für verschiedene Aspekte des Projekts. Solange Sie die Konventionen in Ihrem Projekt befolgen, müssen Sie keine wesentlichen Änderungen an Ihrem Build-Skript vornehmen Sie können den Build ausführen. Wenn Sie die Bedingungen nicht befolgen möchten oder wenn Sie die Bedingungen nicht befolgen können Sie können das Projekt anpassen. Tatsächlich wird die Java-Projektunterstützung als Plug-In implementiert Sie können Java-Projekte ohne Verwendung von Plugins erstellen.
Für Java-Plugins, Abhängigkeitsmanagement und Builds für mehrere Projekte Wir werden in späteren Kapiteln viele Beispiele ausführlicher behandeln. In diesem Kapitel erstellen Sie ein Java-Projekt Ich möchte die erste Idee zur Verwendung des Java-Plug-Ins geben.
Schauen wir uns ein einfaches Beispiel an. Fügen Sie Ihrer Build-Datei die folgende Zeile hinzu, um das Java-Plug-In zu verwenden:
build.gradle
apply plugin: 'java'
Hinweis: Der Code in diesem Beispiel stammt aus der All-Distribution von Gradle. Es kann in samples / java / quickstart gefunden werden.
Dies ist alles, was Sie zum Definieren eines Java-Projekts benötigen. Durch die Beschreibung des oben Gesagten wird das Java-Plug-In auf das Projekt angewendet. Einige Aufgaben werden dem Projekt hinzugefügt.
** Aufgaben, die ausgeführt werden können **
Sie können Gradle-Aufgaben verwenden, um die Aufgaben in Ihrem Projekt aufzulisten. Dies zeigt Ihnen die Aufgaben, die das Java-Plug-In Ihrem Projekt hinzugefügt hat.
Gradle legt den Produktionsquellcode unter src / main / java ab. Versuchen Sie, den Testquellcode unter src / test / java zu finden. Darüber hinaus sind alle Dateien unter src / main / resources als Ressourcen in der JAR-Datei enthalten. Die Dateien unter src / test / resources sind im Klassenpfad enthalten, der zum Ausführen des Tests verwendet wird. Alle Ausgabedateien werden im Build-Verzeichnis erstellt Die JAR-Datei wird im Verzeichnis build / libs gespeichert.
Java-Plug-Ins fügen Ihrem Projekt eine große Anzahl von Aufgaben hinzu. Es sind jedoch nur eine Handvoll Aufgaben erforderlich, um ein Projekt zu erstellen. Die am häufigsten verwendete Aufgabe ist die Erstellungsaufgabe, mit der das Projekt vollständig erstellt wird. Wenn Sie gradle build ausführen, kompiliert und testet Gradle Ihren Code Erstellen Sie eine JAR-Datei, die die Ausführungsklassen und Ressourcen enthält.
** Beispiel 47.2. Erstellen eines Java-Projekts **
Ausgabe beim Ausführen von Gradle Build
> gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build
BUILD SUCCESSFUL in 0s
6 actionable tasks: 6 executed
Hier sind einige nützliche Aufgaben.
clean
Löschen Sie das Build-Verzeichnis und alle erstellten Dateien.
assemble
check
Andere Plugins fügen dieser Aufgabe Elemente hinzu. Wenn Sie beispielsweise das War-Plug-In verwenden, generiert diese Aufgabe auch eine WAR-Datei für Ihr Projekt. Kompilieren und testen Sie Ihren Code. Andere Plugins fügen dieser Aufgabe weitere Überprüfungen hinzu. Zum Beispiel, wenn Sie das Checkstyle-Plugin verwenden Diese Aufgabe führt auch Checkstyle für den Quellcode aus.
Java-Projekte haben normalerweise einige Abhängigkeiten von externen JAR-Dateien. So verweisen Sie auf diese JAR-Dateien in Ihrem Projekt Sie müssen Gradle mitteilen, woher die JAR-Datei stammt. In Gradle werden Artefakte wie JAR-Dateien im Repository gespeichert. Da das Repository die Projektabhängigkeiten erhält, Oder um die Ergebnisse des Projekts zu veröffentlichen Es kann für oder beides verwendet werden. In diesem Beispiel wird ein öffentliches Maven-Repository verwendet.
** Beispiel 47.3. Erstellen eines Maven-Repositorys **
build.gradle
repositories {
mavenCentral()
}
Fügen wir einige Abhängigkeiten hinzu. Hier hat die Produktionsklasse eine Abhängigkeit zur Kompilierungszeit von der Commons-Sammlung. Deklarieren Sie, dass die Testklasse zur Kompilierungszeit von junit abhängt.
** Beispiel 47.4. Abhängigkeitsregistrierung **
build.gradle
dependencies {
compile group: 'commons-collections', name: 'commons-collections', version: '3.2.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
Weitere Informationen finden Sie in Kapitel 8 „Grundlagen des Abhängigkeitsmanagements“.
Java-Plugins fügen Ihrem Projekt einige Eigenschaften hinzu. Diese Eigenschaften werden normalerweise auf Standardwerte gesetzt. Wenn der Standardwert der Eigenschaft nicht übereinstimmt, können Sie den Wert leicht ändern. Schauen wir uns ein Beispiel an. Hier ist die Versionsnummer des Java-Projekts und Gibt die Java-Version an, die die Quelle beschreibt. Außerdem werden dem JAR-Manifest einige Attribute hinzugefügt.
** Beispiel 47.5. Anpassen von MANIFEST.MF **
build.gradle
sourceCompatibility = 1.7
version = '1.0'
jar {
manifest {
attributes 'Implementation-Title': 'Gradle Quickstart',
'Implementation-Version': version
}
}
Sie können die Eigenschaften Ihres Projekts auflisten, indem Sie Gradle-Eigenschaften ausführen. Dadurch werden die vom Java-Plug-In hinzugefügten Eigenschaften und Standardeinstellungen angezeigt.
Die Aufgaben, die das Java-Plug-In hinzufügt, sind genau die gleichen wie die in der Build-Datei deklarierten. Dies ist eine normale Aufgabe. Dies bedeutet, dass Sie diese Aufgaben mithilfe des im vorherigen Kapitel gezeigten Mechanismus anpassen können. Zum Beispiel Festlegen von Aufgabeneigenschaften, Hinzufügen von Verhalten, Sie können Aufgabenabhängigkeiten ändern oder Aufgaben insgesamt ersetzen. Im Beispiel zum Hinzufügen von Systemeigenschaften beim Ausführen des Tests Konfigurieren Sie eine Testaufgabe vom Typ Test.
** Beispiel 47.6. Registrierung der Systemeigenschaften testen **
build.gradle
test {
systemProperties 'property': 'value'
}
Normalerweise sollte die JAR-Datei irgendwo veröffentlicht werden. Dazu müssen Sie Gradle mitteilen, wo die JAR-Datei veröffentlicht werden soll. Gradle veröffentlicht Artefakte wie JAR-Dateien im Repository. Das Beispiel macht es einem lokalen Verzeichnis zugänglich. Sie können auch an einem Remotestandort oder an mehreren Standorten veröffentlichen.
** Beispiel 47.7. JAR-Datei veröffentlichen **
build.gradle
uploadArchives {
repositories {
flatDir {
dirs 'repos'
}
}
}
Führen Sie gradle uploadArchives aus, um die JAR-Datei zu veröffentlichen.
So erstellen Sie eine Eclipse-spezifische Deskriptordatei wie .project Sie müssen Ihrer Build-Datei ein weiteres Plug-In hinzufügen.
** Beispiel 47.8. Eclipse Plugin **
build.gradle
apply plugin: 'eclipse'
Führen Sie den Befehl gradle eclipse aus, um die Eclipse-Projektdatei zu generieren. Weitere Informationen zu Eclipse-Aufgaben finden Sie in Kapitel 67, "Eclipse-Plugins" (https://docs.gradle.org/4.4.1/userguide/eclipse_plugin.html).
Hier ist ein Beispiel für eine vollständige Beispiel-Build-Datei.
** Beispiel 47.9. Java-Beispiel - Vollständige Build-Datei **
build.gradle
apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = 1.7
version = '1.0'
jar {
manifest {
attributes 'Implementation-Title': 'Gradle Quickstart',
'Implementation-Version': version
}
}
repositories {
mavenCentral()
}
dependencies {
compile group: 'commons-collections', name: 'commons-collections', version: '3.2.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
test {
systemProperties 'property': 'value'
}
uploadArchives {
repositories {
flatDir {
dirs 'repos'
}
}
}
Schauen wir uns als nächstes einen typischen Multiprojekt-Build an. Veranschaulichen Sie die Struktur des Projekts.
** Beispiel 47.10. Hierarchisches Layout für mehrere Projekte **
Konfiguration erstellen
multiproject/
api/
services/webservice/
shared/
services/shared/
Hinweis: Dieser Beispielcode stammt aus der All-Distribution von Gradle Es ist in samples / java / multiproject beschrieben.
Hier gibt es vier Projekte. Das API-Projekt generiert eine JAR-Datei und Stellt dem Client einen Java-Client für XML-Webdienste zur Verfügung. Ein Webservice-Projekt ist eine Webanwendung, die XML zurückgibt. Das gemeinsam genutzte Projekt enthält Code, der sowohl von der API als auch vom Webservice verwendet wird. Das Services / Shared-Projekt verfügt über Code, der vom Shared-Projekt abhängt.
Um einen Build für mehrere Projekte zu definieren, müssen Sie eine Konfigurationsdatei erstellen. Die Konfigurationsdatei befindet sich im Stammverzeichnis des Quellbaums Gibt die Projekte an, die in den Build aufgenommen werden sollen. Die Einstellungsdatei muss immer den Namen settings.gradle haben. In diesem Beispiel wird ein einfaches hierarchisches Layout verwendet. Die entsprechende Konfigurationsdatei ist unten dargestellt.
** Beispiel 47.11. Datei für mehrere Projekte build-settings.gradle **
settings.gradle
include "shared", "api", "services:webservice", "services:shared"
Weitere Informationen zu Konfigurationsdateien finden Sie in Kapitel 26, "Multi-Project Builds" (https://docs.gradle.org/4.4.1/userguide/multi_project_builds.html).
Für die meisten Builds mit mehreren Projekten Es gibt einige Einstellungen, die allen Projekten gemeinsam sind. Im Beispiel verwenden wir eine Technik namens Konfigurationsinjektion. Definieren Sie diese allgemeine Einstellung im Stammprojekt. Das Root-Projekt ist wie ein Container Die Teilprojektmethode durchläuft die Elemente dieses Containers (das Projekt der Instanz) und Injiziert die angegebenen Einstellungen. Auf diese Weise alle Archive und einige Definieren Sie einfach Manifestinhalte für allgemeine Abhängigkeiten.
** Beispiel 47.12. Gemeinsame Einstellungen für mehrere Projekte **
build.gradle
subprojects {
apply plugin: 'java'
apply plugin: 'eclipse-wtp'
repositories {
mavenCentral()
}
dependencies {
testCompile 'junit:junit:4.12'
}
version = '1.0'
jar {
manifest.attributes provider: 'gradle'
}
}
In diesem Beispiel wird das Java-Plug-In auf jedes Teilprojekt angewendet. Dies liegt an den Aufgaben und Konfigurationseigenschaften, die wir im vorherigen Abschnitt gesehen haben Dies bedeutet, dass es in jedem Teilprojekt verwendet werden kann. Daher können Sie gradle build aus dem Stammprojektverzeichnis ausführen Sie können JARs für alle Ihre Projekte kompilieren, testen und generieren. Außerdem befinden sich diese Plugins nicht auf der Root-Ebene Es gilt also nur für den Teilprojektabschnitt Der Root-Build versucht nicht, Java-Quelldateien im Root-Projekt zu finden Suche nur innerhalb von Teilprojekten.
Sie können Abhängigkeiten zwischen Projekten im selben Build hinzufügen. Verwenden Sie beispielsweise die JAR-Datei für ein Projekt Sie können ein anderes Projekt kompilieren. Die API-Build-Datei fügt dem freigegebenen Projekt eine Abhängigkeit hinzu. Aufgrund dieser Abhängigkeit startet Gradle immer vor dem Erstellen eines API-Projekts. Erstellen Sie ein gemeinsames Projekt.
** Beispiel 47.13. Mehrprojekt-Build-Abhängigkeiten zwischen Projekten **
api/build.gradle
dependencies {
compile project(':shared')
}
Informationen zum Deaktivieren dieser Funktion Siehe Abschnitt 26.7.1, „Deaktivieren abhängiger Projektbuilds“ (https://docs.gradle.org/4.4.1/userguide/multi_project_builds.html#disable_dependency_projects).
Fügen Sie die Artefakte hinzu, die an den Client verteilt werden.
** Beispiel 47.14. Build-Distribution-Datei für mehrere Projekte **
api/build.gradle
task dist(type: Zip) {
dependsOn spiJar
from 'src/dist'
into('libs') {
from spiJar.archivePath
from configurations.runtime
}
}
artifacts {
archives dist
}
In diesem Kapitel müssen Sie ein Java-basiertes Projekt erstellen Wir haben gesehen, wie einige der Aufgaben ausgeführt werden. Dieses Kapitel erhebt keinen Anspruch auf Vollständigkeit. Es gibt viele andere Dinge, die Sie mit Gradles Java-Projekt tun können. Weitere Informationen zu Java-Plugins finden Sie in Kapitel 48, "Java-Plugins" (https://docs.gradle.org/4.4.1/userguide/java_plugin.html). Außerdem ein Java-Beispielprojekt aus der Gradle-Distribution Befindet sich im Verzeichnis samples / java. Andernfalls fahren Sie mit Kapitel 8, "Grundlagen des Abhängigkeitsmanagements" (https://docs.gradle.org/4.4.1/userguide/artifact_dependencies_tutorial.html) fort.
Recommended Posts