Mam skrypt budowania Gradle ( build.gradle
), w którym utworzyłem kilka zadań. Te zadania składają się głównie z wywołań metod. Wywołane metody znajdują się również w skrypcie budowania.
Oto sytuacja:
Tworzę sporo skryptów kompilacji, które zawierają różne zadania, ale używam tych samych metod, co oryginalny skrypt. Dlatego chciałbym w jakiś sposób wyodrębnić te "powszechne metody", aby móc z łatwością ich używać ponownie, zamiast kopiować je dla każdego nowego skryptu, który tworzę.
Gdyby Gradle był PHP, idealne byłoby coś takiego:
//script content
...
require("common-methods.gradle");
...
//more script content
Ale oczywiście nie jest to możliwe. Albo to jest?
Zresztą, jak mogę osiągnąć taki wynik? Jaka jest najlepsza możliwa metoda, aby to zrobić? Przeczytałem już dokumentację Gradle, ale nie mogę określić, która metoda będzie najłatwiejsza i najlepiej do tego nadaje się.
Z góry dziękuję!
AKTUALIZACJA:
Udało mi się wyodrębnić metody w innym pliku
(używając apply from: 'common-methods.gradle'
),
więc struktura jest następująca:
parent/
/build.gradle // The original build script
/common-methods.gradle // The extracted methods
/gradle.properties // Properties used by the build script
Po wykonaniu zadania z poziomu build.gradle
napotkałem nowy problem: najwyraźniej metody nie są rozpoznawane, gdy się pojawią common-methods.gradle
.
Jakieś pomysły, jak to naprawić?
źródło
timestamp()
lubcurrentWorkingDirectory()
metody jakotask
-s (na przykład). Funkcje narzędziowe i podobne rzeczy są nominalnie skalarne - nie byłyby zadaniami, z wyjątkiem tego, że istnieją ograniczenia dotyczące ponownego wykorzystania kodu wbudowane w Gradle i większość systemów kompilacji. Lubię świat SUCHEGO, w którym mogę zrobić coś JEDEN raz i użyć tego ponownie. W rzeczywistości, rozszerzając przykład @Pieter VDE, używam równieżroot.gradle
wzorca " " dla mojego projektu nadrzędnego - plik build.gradle zwykle definiuje pewne szczegóły projektu, a potem po prostuapply ${ROOT}
...Odpowiedzi:
Nie można udostępniać metod, ale możesz udostępniać dodatkowe właściwości zawierające zamknięcie, które sprowadza się do tego samego. Na przykład zadeklaruj
ext.foo = { ... }
wcommon-methods.gradle
, użyj,apply from:
aby zastosować skrypt, a następnie wywołaj zamknięcie za pomocąfoo()
.źródło
File foo(String f)
się stanieext.foo = { f -> ... }
, czy mogę wtedy po prostu zrobić coś takiegoFile f = foo(...)
:?Opierając się na odpowiedzi Petera , eksportuję moje metody w następujący sposób:
Treść
helpers/common-methods.gradle
:// Define methods as usual def commonMethod1(param) { return true } def commonMethod2(param) { return true } // Export methods by turning them into closures ext { commonMethod1 = this.&commonMethod1 otherNameForMethod2 = this.&commonMethod2 }
A tak używam tych metod w innym skrypcie:
// Use double-quotes, otherwise $ won't work apply from: "$rootDir/helpers/common-methods.gradle" // You can also use URLs //apply from: "https://bitbucket.org/mb/build_scripts/raw/master/common-methods.gradle" task myBuildTask { def myVar = commonMethod1("parameter1") otherNameForMethod2(myVar) }
Oto więcej informacji na temat konwersji metod na zamknięcia w Groovy.
źródło
ext
.Używając Kotlin dsl działa to tak:
build.gradle.kts :
external.gradle.kts :
źródło
Innym podejściem do Kotlin DSL może być:
my-plugin.gradle.kts
settings.gradle.kts
źródło