Что такое построение по соглашению в глубоком объяснении Gradle?

Руководство пользователя Gradle часто упоминает, что Gradle декларативно и использует встроенные по-конвенции. Что это значит?

Из того, что я понимаю, это означает, что, например, в java- плагине существуют соглашения, такие как source, должны быть в src/main/java, тесты должны быть в src/main/test, ресурсы в src/main/resources, готовые банки в build/libs и т.д. Однако Gradle не обязывает вас использовать эти соглашения, и вы можете изменить их, если хотите.

Но со второй концепцией у меня есть большая проблема с пониманием. Как и SQL, вы говорите, что хотите делать с вашими запросами, но не говорите, как система базы данных их получит, какой алгоритм использовать для извлечения данных и т.д.

Пожалуйста, расскажите мне больше, чтобы правильно понять эти понятия. Благодарю.

Ответ 1

Ваше понимание сборки по соглашению правильное, поэтому мне нечего туда добавлять. (Также см. Ответ Джеффа.)

Идея декларативного заключается в том, что вам не нужно работать на уровне задачи, выполнять/декларировать/настраивать все задачи и их зависимости самостоятельно, но может работать на более высоком, более декларативном уровне. Вы просто говорите "это проект Java" (apply plugin: "java"), "вот мой бинарный репозиторий" (repositories {... }), "вот мои источники" (sourceSets {... }), "это мои зависимости" (dependencies {... }). Основываясь на этой декларативной информации, Gradle затем выяснит, какие задачи требуются, каковы их зависимости и как их нужно настраивать.

Ответ 2

Чтобы понять декларативный стиль программирования, полезно сравнить и противопоставить его против императивного стиля программирования.

Декларативное программирование позволяет нам указать, что мы хотим сделать.

В Императорском программировании мы указываем, как мы что-то делаем.

Поэтому, когда мы используем gradle, как описывает Питер, мы делаем декларации, такие как: "Это Java-проект" или "Это веб-приложение Java",

Затем Gradle использует плагины, которые предлагают услугу обработки таких вещей, как "Java-проекты" или "Веб-приложения". Это хорошо, потому что это плагин Gradle, который содержит детали реализации, которые относятся к таким задачам, как компиляция классов Java и создание военных файлов.

Сравните это с другой системой сборки, Make, которая более необходима в природе. Давайте взглянем на простое правило "Сделать", взятое отсюда:

 foo.o : foo.c defs.h       
         cc -c -g foo.c

Итак, здесь мы видим правило, описывающее, как построить объектный файл foo.o из исходного файла C и файла заголовка C.

Правило Make делает две вещи.

В первой строке говорится, что файл foo.o зависит от foo.c и foo.h. Эта строка является своеобразной декларативной, поскольку Make знает, как проверить метку времени на файле foo.o, чтобы узнать, если она старше файлов foo.c и foo.h. и если foo.o старше, то Make будет вызывать следующую команду на следующей строке.

Следующая строка является императивной.

Вторая строка точно определяет, какую команду запускать (cc - компилятор C), когда файл foo.o старше любого из файлов foo.c или foo.h. Также обратите внимание, что человек, который пишет правило Makefile, должен знать, какие флаги передаются команде cc.

Ответ 3

Построить по соглашению - идея, что если вы будете следовать соглашениям по умолчанию, ваши сборки будут намного проще. Поэтому, хотя вы можете изменить исходный каталог, вам не нужно явно указывать исходный каталог. Gradle поставляется с логическими значениями по умолчанию. Это также называется условной конфигурацией.

Эта часть отредактирована для более четкого описания декларативного характера, основанного на ответе Питера:

Идея создания декларации заключается в том, что вам не нужно указывать каждый шаг, который необходимо выполнить. Вы не говорите "сделайте шаг 1, сделайте шаг 2 и т.д.". Вы определяете плагины (или задачи), которые необходимо применять, и градиент, затем строит график выполнения задачи и вычисляет, какой заказ выполнять.