Ich schreibe einen Gradle-Build für ein Nicht-Java-Projekt, um vorhandene Verzeichnisse und tar-Archive in eine .tar.gz-Datei zu mappen. Die tar-Task überspringt, wenn ich die Definition so verwende:
%Vor%Hier ist die Konsolenausgabe
%Vor%Wenn ich versuche, die tar-Aufgabe als Methode zu verwenden, schlägt die Beschwerde fehl, die Methode
kann nicht gefunden werden %Vor%Können wir die tar-Task auf die gleiche Weise ausführen, wie Gradle das Ausführen von copy erlaubt? Im selben Build habe ich einen Block wie folgt und ich möchte wissen, ob Teer auf die gleiche Weise verwendet werden kann
%Vor%Wenn nicht, wie stelle ich sicher, dass mein Build nicht die Task "tar überspringen", wenn das oben beschriebene erste Formular verwendet wird.
Sie haben sich auf den klassischen Fehler gefasst, eine Aufgabe in der Ausführungsphase anstatt in der Konfigurationsphase zu konfigurieren. Die Lösung besteht darin, das << im ersten Code-Snippet zu entfernen.
Wenn Sie das << (und den Unterschied, den es macht) verwirren, ist es eine gute Lösung, niemals << , sondern immer das explizite doLast {} zu verwenden.
Es gibt keine tar -Methode, aber es ist normalerweise besser, diese Dinge trotzdem zu einer separaten Aufgabe zu machen. (Methoden wie copy sollten gegenüber der entsprechenden Aufgabe nur dann bevorzugt werden, wenn es einen starken Grund gibt.)
Ich hatte eine witzige Situation, in der ich bei der Verwendung von doLast {} auf eine tar-Aufgabe traf.
Es war wegen einer Multi-Projekt-Build:
%Vor% In diesem Fall, wenn Sie versuchen, eine tar oder eine copy Aufgabe in der Haupt-Build-Datei zu haben, die etwas von dieser project(":sub-project") referenziert, wird es den Entwickler dazu verleiten, es in doLast zu verpacken.
Zum Beispiel hat die Hauptdatei build.gradle:
%Vor% Sie haben also einen Fehler bekommen, dass project(":sub-project").war nicht existiert. Um es zu umgehen, setzte jemand doLast {} auf die Aufgabe und Fehler gingen weg. SCHLECHT !!
Dann musste ich es reparieren. Also war es richtig, es hinzuzufügen
evaluationDependsOn ":sub-project"
In der Hauptdatei build.gradle. Jetzt weiß es, es zu bewerten. Ich entferne den inkorrekten doLast{} Block und jetzt wird die Aufgabe nicht mehr ignoriert.