Как я продемонстрировал в посте «Первый взгляд на создание Java с помощью Gradle» , Gradle особенно лаконичен и прост в применении к основам построения приложений Java, когда кто-либо использует плагин Java и размещает файлы и каталоги там, где этот плагин ожидает их ( на основе макета проекта ). Однако не всегда возможно иметь структуру (особенно в устаревших системах), отвечающую ожидаемым соглашениям Gradle. В этой статье я расскажу о переопределении некоторых соглашений Gradle Java Plugin, чтобы позволить простой сборке Gradle работать с различными структурами каталогов.
В приведенном ниже листинге кода содержится код Gradle для сборки build.gradle . Я включил комментарии в код сборки, чтобы помочь объяснить, что делает каждый тип настройки.
build.gradle
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
// build.gradle//// This simple example of a Gradle build file exists primarily to demonstrate// approaches to overriding Gradle's default conventions related to use of the// Java plugin.// The 'java' plugin must be applied before attempting to access the sourceSets// and other properties defined by the Java plugin to avoid an error message// similar to the following: "Could not find method sourceSets() for arguments..."apply plugin: 'java'// Redefine where Gradle should expect Java source files (*.java)sourceSets { main { java { srcDirs 'java' } resources { srcDir 'resources' } }}// Redefine where .class files are writtensourceSets.main.output.classesDir = file("dist/classes")// Redefine where 'jar' task should place generated JAR file.jar { destinationDir = file('dist/jar')}// Fully qualified directory/JAR for Guava Release 16 JAR file:// C:\\guava16\\guava-16.0-rc1.jarrepositories { flatDir{ dirs 'C:\\guava16' } }dependencies { compile 'guava:guava:16.0-rc1'}defaultTasks 'clean', 'jar' |
Файл сборки Gradle, показанный выше, сначала применяет плагин Java. Затем он переопределяет обычные расположения Gradle для исходных файлов Java (каталог самого высокого уровня, где подкаталоги представляют пакеты, а файлы имеют расширения .jar), изменяя этот каталог со значения по умолчанию src/main/java на просто java . Точно так же расположение src/main/resources по умолчанию для производственных ресурсов изменяется на просто resources .
Файл сборки, показанный выше, затем изменяется, где файлы * .class (с соответствующими подкаталогами, представляющими их структуру пакета), указав, что sourceSets.main.output.classesDir теперь является dist/classes ( build/classes/main — это стандартное значение по умолчанию). Аналогично, destinationDir задачи jar переопределяется так, чтобы указывать на dist/jar ( build/libs — соглашение), и именно здесь записывается файл JAR, созданный задачей jar .
Последней настройкой, показанной в простом скрипте сборки Gradle, показанном выше, является спецификация «репозиториев» и «зависимостей», чтобы сделать JAV Guava Release 16 доступным для моего приложения (что зависит от Guava Release 16). Gradle предоставляет сложную поддержку для использования репозиториев Maven или Ivy, включая специальный синтаксис для Maven Central , но этот конкретный пример получает JAR Guava Release 16 из моей локальной файловой системы (C: \ guava16). Сама зависимость выражается как «guava: guava: 16.0-rc1», потому что JAR в указанном каталоге хранилища называется «guava-16.0-rc1.jar».
Чтобы упростить тестирование этих настроек, я явно указал defaultTasks как clean и jar поэтому все, что мне нужно было сделать, это набрать gradle в командной строке, пока я находился в том же каталоге, что и файл build.gradle показанный выше, и как пока на этом уровне был подкаталог «java» с исходными файлами .java в соответствующих каталогах на основе пакетов.
Сборки Gradle являются наиболее краткими и легкими для записи и чтения, когда соблюдаются соглашения Gradle. Однако не так сложно переопределить эти условные обозначения и указать настраиваемую конфигурацию для соответствия устаревшим системам.