Jaka jest różnica w stosowaniu wtyczki gradle


186

Nie rozumiem bloku wtyczek gradle

apply plugin: 'someplugin1'
apply plugin: 'maven'

i drugi:

plugins {
   id 'org.hidetake.ssh' version '1.1.2'
}

W pierwszym bloku Mamy nazwę wtyczki. w drugim pakiecie i wersji. Nie rozumiem, gdzie powinienem użyć pierwszego bloku, a kiedy drugiego.


30
Dzięki Gradle przygotuj się na zobaczenie ponad 2 sposobów na zrobienie tego samego!
Paulo Merson

7
Gradle to Perl systemów kompilacji.
sakra

Odpowiedzi:


177

pluginsBlok jest nowszy sposób zastosowania wtyczki i muszą być dostępne w Gradle repozytorium wtyczki . applyPodejście jest starszy, jeszcze bardziej elastyczny sposób dodawania wtyczki do kompilacji.

Nowa pluginsmetoda nie działa w konfiguracjach obejmujących wiele projektów ( subprojects, allprojects), ale działa w konfiguracji kompilacji dla każdego projektu potomnego.

Sądzę, że wraz z postępem funkcjonalności pluginsmetoda konfiguracji zastąpi starsze podejście, ale w tym momencie oba mogą być i są używane jednocześnie.


4
Należy pamiętać, że zastosowanie wtyczki przy użyciu wtyczek DSL ( plugins {...}) nie działa w przypadku wtyczek prywatnych lub firmowych, które nie są publikowane w oficjalnym repozytorium wtyczek Gradle. Dlatego mam nadzieję, że stare podejście przynajmniej przetrwa, dopóki nowe nie będzie obsługiwać wyszukiwania w prywatnych repozytoriach.
Datz

2
pluginsdziała w wielu projektach, zgodnie z samouczkiem Gradle (Gradle wersja 5.6.2) guide.gradle.org/creating-multi-project-builds/... Używa pluginsbloku z, apply falseaby dodać wtyczkę do całego projektu, ale nie dodaje do głównego projektu. Podprojekt pluginsponownie używa bloków, aby dodać wtyczkę.
yetsun

Naprawdę nie ma sensu używać pluginsover apply plugin.
sakra

1
2020 i nadal używamapply plugin
Blundell

Jest to absolutnie okropne, dwie dyrektywy z zupełnie inną składnią i wejściami, a ponadto niekompatybilne. Gradle jest zdecydowanie największym bólem szyi przy użyciu Javy i Kotlina.
Christian

57

Jak już wspomniano @cjstehno, apply pluginjest to starsza metoda, której należy unikać.

Wraz z wprowadzeniem wtyczek DSL użytkownicy nie powinni mieć powodu, aby stosować starszą metodę stosowania wtyczek. Jest to udokumentowane tutaj na wypadek, gdyby autor kompilacji nie mógł użyć wtyczek DSL z powodu ograniczeń w tym, jak obecnie działa.

Dzięki nowej plugins blockmetodzie możesz dodać wtyczkę i kontrolować, kiedy ją zastosować, używając opcjonalnego parametru apply:

plugins {
    id «plugin id» version «plugin version» [apply «false»]
}

Nadal używałbyś starszej metody w sytuacjach, w których chcesz zastosować już dodaną, ale nie zastosowaną wtyczkę w swoim pluginsbloku. Np. W projekcie głównym wtyczka xyzjest dodawana, ale nie stosowana, i powinna być stosowana tylko w podprojekcie subPro:

plugins {
  id "xyz" version "1.0.0" apply false
}

subprojects { subproject ->
    if (subproject.name == "subPro") {
        apply plugin: 'xyz'
    }
}

Zauważ, że nie potrzebujesz już wersji. Wersja jest wymagane w pluginsbloku chyba że używasz jednej z wtyczek Rdzeń Gradle, takich jak java, scala...

Spędziłem trochę czasu na zrozumieniu różnicy, próbując utworzyć Spring Bootaplikację, i dlatego po chwili odpowiadam na to ponownie. Poniższy przykład użycia Spring Bootwtyczki bardzo mi pomógł:

Czego należy obecnie używać:

plugins {
  id "org.springframework.boot" version "2.0.1.RELEASE"
}

Co było używane przed Gradle 2.1:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.springframework.boot:spring-boot-gradle-plugin:2.0.1.RELEASE"
  }
}

apply plugin: "org.springframework.boot"

To w jakiś sposób daje złe wrażenie. Nie można po prostu przejść apply plugin xxxna plugins { id xxx }(próbowałem i nie zadziałało)
Christian

Myślę, że odpowiedź i cytowana dokumentacja wyraźnie to stwierdzają. To zależy od twojej sprawy. Możesz podać więcej informacji na temat swojej sprawy lub opublikować to w innym pytaniu.
Mousa
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.