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.