Какова цель папки gradle buildSrc?

В gradle, какова цель использования файла buildSrc как верхнего уровня, а не только типичного макета проекта Java (src/main/java)?

Если у меня есть макет

src
   main
      java

или

buildSrc
    src
       main
          java

Какая разница (или причина для этого)? Это более полезно в проектах с несколькими модулями? Даже для проекта с несколькими модулями я не мог бы сделать что-то вроде

proj1
  src


proj2
  src

И тогда у вас есть только верхний уровень build.gradle(на уровне proj1 и proj2), который определяет общие настройки в проектах?

Ответ 1

buildSrc - это отдельная сборка, целью которой является сборка любых задач, плагинов или других классов, которые предназначены для использования в скриптах сборки основной сборки, но не должны использоваться совместно для сборки. (* ) Невозможно построить такие классы как часть основной сборки, потому что они должны существовать до того, как скрипты сборки основной сборки могут даже быть скомпилированы/оценены, а Gradle компилирует/оценивает все скрипты сборки, прежде чем работа (конфигурация или фаза выполнения).

По сравнению с размещением кода сборки в скриптах сборки, buildSrc дает вам способ разработать код сборки, более похожий на обычный код, как классы, которые вы можете протестировать, импортировать в свою среду IDE и т.д. Это один из способов сохранить сборку скрипты простые и сухие даже для более сложных построек.

buildSrc чаще встречается в многопроектных сборках просто потому, что более крупные сборки чаще реализуют свои собственные задачи и плагины.

С течением времени buildSrc превратится в более общую возможность выполнения нескольких зависимых построений в одном вызове Gradle.

(*) Совместное использование классов в сборках возможно, но более активно. В частности, вам нужно будет публиковать классы в репозитории, а потребляющие сборки должны явно импортировать их там, подобно тому, как они разделяют производственные библиотеки между сборками.

Ответ 2

В Gradle, какова цель использования файла buildSrc в качестве верхнего уровня, в отличие от обычного макета проекта Java (src/main/java)?

Вы определенно можете сделать это. Он известен как составная сборка в Gradle, но вы должны указать Gradle включить любые сборки из этой папки. Уникальным свойством папки buildSrc верхнего уровня является то, что gradle автоматически обрабатывает ее как включенную сборку.

Обратите внимание, что хотя buildSrc рассматривается как составная сборка, она не отображается в списке включенных сборок при запуске gradle.getIncludedBuilds(). Я считаю, что причина в том, что список зарезервирован для сборок, которые вы вручную включили в ваш файл settings.gradle.

Чтобы вы также включили src/main/java в качестве составной сборки, вы должны запустить свой скрипт gradle, используя флаг --include --include-build, а затем путь к src/main/java. Это необычное место для включенной сборки, но Gradle не будет жаловаться.

И тогда просто есть build.gradle верхнего уровня (на том же уровне, что и proj1 и proj2), который определяет общие настройки для проектов?

Вы МОЖЕТЕ иметь верхний уровень build.gradle на том же уровне, что и ваши proj1 и proj2. Как правило, именно так структурируется большинство мультипроектных проектов.


Как уже отмечалось в ответе, целью проекта buildSrc является создание пользовательских плагинов или задач, которые предназначены для совместного использования локально между различными проектами в вашей сборке. Это не означает, что вы не можете создавать эти пользовательские задачи и плагины в своем build.gradle верхнего уровня. Вы можете сделать это таким образом, но проблема в том, что вы не сможете использовать его ни в одном из ваших подпроектов.

Помните, что для того, чтобы импортировать что-либо в java/groovy, необходимо, чтобы эта вещь существовала в надлежащем файле java/groovy (или в модуле для java 9+). Видя, что ваш build.gradle - это просто скрипт, не просто импортировать из него плагин или задачу.

Как я уже указывал, и это из документации Gradle, одна из причин наличия каталога buildSrc:

После обнаружения каталога Gradle автоматически компилирует и тестирует этот код и помещает его в путь к классу вашего сценария сборки.

Как вы можете видеть, buildSrc действует как расширение вашего процесса сборки в том смысле, что он может добавить дополнительную функциональность ко всем сценариям сборки вашего проекта.


Еще несколько моментов:

  • Любые dependencies объявленные в вашем buildSrc/build.gradle, видны остальным сценариям сборки в вашем проекте.
  • Блок buildscript в вашем buildSrc/build.gradle только для buildSrc/build.gradle и больше ничего.
  • Любой класс плагинов, определенный в buildSrc может использоваться в любом скрипте сборки в вашем проекте, и его не нужно объявлять в META-INF/gradle-plugins.
  • Любые зависимости, определенные в вашем основном build.gradle или любом из ваших подпроектов, не видны в buildSrc. Если вы помните, что эта папка рассматривается как включенная сборка (т.е. Внешняя), то должно иметь смысл, почему она не видит путь к классу проекта, который ее включает.