Gradle-Batch-Task, der Unterprojekte und andere Tasks in der richtigen Reihenfolge aufruft

Question

Gradle-Batch-Task, der Unterprojekte und andere Tasks in der richtigen Reihenfolge aufruft

8

Ich schreibe gradle 1.4 Build-Datei für Multimodul-Projekt. Also gibt es root build.gradle , das etwas wie folgt definiert:

%Vor%

definiert die Aufgabe build für alle Submodule. Submodule sind in settings.gradle enthalten und jedes Modul hat seine Build-Datei mit definierten Abhängigkeiten.

Alles bisher im Buch :) Jetzt habe ich in der Haupt-Build-Datei einige zusätzliche Aufgaben für den Projektumfang hinzugefügt, wie: aggregateJavadoc (sammelt alle javadocs zu einem zusammen) oder bundleJar (erzeugt Bündel-Jar von allen Klassen), usw. Jedes on funktioniert, wenn es manuell aufgerufen wird.

Jetzt brauche ich eine Aufgabe release das wird

Erzeuge alle Submodule (wie von der Kommandozeile aufgerufen - was bedeutet, dass ich execute () für jedes Submodul nicht manuell schreiben will)
ruft zusätzliche Aufgaben auf (mit execute () nehme ich an).

Ich habe dependsOn versucht, aber die Reihenfolge der aufgelisteten Aufgaben wird nicht befolgt. Außerdem scheinen abhängige Module nach der Ausführung der Release-Task ausgeführt zu werden. Ich habe mehrere andere Ideen ausprobiert und ist gescheitert.

Frage: Was wäre der beste Weg, um eine solche Batch-Aufgabe zu erstellen, die auf allen Submodulen etwas aufrufen muss und zusätzlich einige Aufgaben ausführen soll? Was wäre die beste graddle-freundliche Lösung? Danke!

gradle

igr 30.01.2013, 12:41
quelle

1 Antwort

9

Es ist passiert, dass dies mit einem einfachen Abhängigkeitsmanagement gelöst werden kann.

Also, wir haben viele Module. Erstellen Sie nun zusätzliche Aufgaben, die von den zu erstellenden Modulen abhängen:
%Vor%
Schließlich würde unsere release Aufgabe einfach so aussehen:
%Vor%
Dies wird zuerst Teilprojekte erstellen; nicht weil es zuerst aufgeführt wird, sondern weil zusätzliche Aufgaben vom Aufbau abhängen. Reihenfolge der zusätzlichen Aufgabe ist nicht wichtig. Das macht für mich am meisten Sinn.

BEARBEITEN Wenn eines Ihrer Unterprojekte (z. B. Module) ein Nicht-Java-Modul ist, wird das Erstellen dieses Projekts Probleme bereiten. Was ich mache ist Submodulen wie folgt zu gruppieren:
%Vor%
und dann, um auf subprojects zu verweisen, verwenden Sie javaModules überall! Zum Beispiel:
%Vor%
und
%Vor%
Übrigens verwende ich diese Dummy-Aufgabe prj für dependsOn für all diese zusätzlichen Projekte, die vom Aufbau abhängig sind, um Wiederholungen zu vermeiden.

igr 30.01.2013, 16:35
quelle

Tags und Links gradle

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wählen Sie Spalte 2 für die letzte Spalte in R aus

score 9 · Accepted Answer

Es ist passiert, dass dies mit einem einfachen Abhängigkeitsmanagement gelöst werden kann.

Also, wir haben viele Module. Erstellen Sie nun zusätzliche Aufgaben, die von den zu erstellenden Modulen abhängen:

%Vor%

Schließlich würde unsere release Aufgabe einfach so aussehen:

%Vor%

Dies wird zuerst Teilprojekte erstellen; nicht weil es zuerst aufgeführt wird, sondern weil zusätzliche Aufgaben vom Aufbau abhängen. Reihenfolge der zusätzlichen Aufgabe ist nicht wichtig. Das macht für mich am meisten Sinn.

BEARBEITEN Wenn eines Ihrer Unterprojekte (z. B. Module) ein Nicht-Java-Modul ist, wird das Erstellen dieses Projekts Probleme bereiten. Was ich mache ist Submodulen wie folgt zu gruppieren:

%Vor%

und dann, um auf subprojects zu verweisen, verwenden Sie javaModules überall! Zum Beispiel:

%Vor%

und

%Vor%

Übrigens verwende ich diese Dummy-Aufgabe prj für dependsOn für all diese zusätzlichen Projekte, die vom Aufbau abhängig sind, um Wiederholungen zu vermeiden.