Яка різниця у застосуванні плагіну gradle


187

Я не розумію блок плагінів gradle

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

та інше:

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

У першому блоці у нас є ім’я плагіна. у другому одному пакеті та версії. Я не розумію, де я повинен використовувати перший блок, а коли другий.


30
З Gradle готуйтеся до перегляду 2+ способів зробити те саме!
Пауло Мерсон

7
Gradle - це система Perl build.
сакра

Відповіді:


178

pluginsБлок є новим методом застосування плагін, і вони повинні бути доступні в Gradle сховища плагін . applyПідхід є старшим, але більш гнучкий метод додавання плагіна до вашої збірки.

Новий pluginsметод не працює в конфігураціях багатопроекту ( subprojects, allprojects), але буде працювати над конфігурацією збірки для кожного дочірнього проекту.

Я думаю, що в міру розвитку функціональності pluginsметод конфігурації обійде старіший підхід, але в цей момент і те, і інше може бути і застосовуватися одночасно.


4
Майте на увазі, що застосування плагіна за допомогою плагінів DSL ( plugins {...}) не працює для ваших приватних плагінів або плагінів компанії, які не публікуються в офіційному репортажі плагінів Gradle. Тому я сподіваюсь, що старий підхід протримається принаймні до тих пір, поки новий не підтримає пошук у приватних сховищах.
Datz

2
pluginsпрацює в мультипроектному підручнику Gradle (версія Gradle 5.6.2) guides.gradle.org/creating-multi-project-builds/… Він використовує pluginsблок з apply falseдля додавання плагіна до загального проекту, але не додає це до кореневого проекту. Підпроект pluginsзнову використовує блоки для додавання плагіна.
yetsun

Немає сенсу використовувати pluginsбільше apply plugin.
сакра

1
2020, і я все ще використовуюapply plugin
Blundell

Це абсолютно жахливо, дві директиви з абсолютно різними синтаксисами та входами, поверх яких є несумісними. Gradle - це найбільший біль у шиї при використанні Java та Kotlin.
Крістіан

57

Як уже згадував @cjstehno apply plugin, це старий метод, якого слід уникати.

З введенням DSL плагінів, у користувачів не повинно бути причин використовувати застарілий метод застосування плагінів. Це задокументовано в тому випадку, якщо автор збірки не може використовувати плагіни DSL через обмеження в його роботі.

За допомогою нового plugins blockметоду ви можете додати плагін і керувати, коли його застосовувати, використовуючи додатковий параметр apply:

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

Ви все одно будете використовувати застарілий метод у ситуаціях, коли ви хочете застосувати вже доданий, але не застосований плагін у своєму pluginsблоці. Наприклад, у головний проект додаток xyzдодається, але не застосовується, і він повинен застосовуватися лише у підпроекті subPro:

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

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

Зауважте, що версія вам більше не потрібна. Версія потрібно в pluginsблоці , якщо ви не використовуєте один з модулів ядра Gradle, наприклад java, scala...

Я витратив деякий час на розуміння різниці, намагаючись створити Spring Bootдодаток, і тому через деякий час я знову відповідаю на це. Наступний приклад використання Spring Bootплагіна мені дуже допоміг:

Що слід використовувати зараз:

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

Що було використано до 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"

Це якось справляє неправильне враження. Неможливо просто перетворитись apply plugin xxxна це plugins { id xxx }(я спробував це і не вийшло)
Крістіан

Я думаю, що у відповіді та цитованій документації це чітко зазначено. Це залежить від вашого випадку. Ви можете надати більше інформації про свою справу або опублікувати це в іншому запитанні.
Муса
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.