Gradle: build.gradle vs. settings.gradle vs. gradle.properties

1. Ikhtisar

Dalam artikel ini, kita akan melihat berbagai file konfigurasi dari proyek Gradle Java . Selain itu, kita akan melihat detail dari build yang sebenarnya.

Anda dapat memeriksa artikel ini untuk pengenalan umum tentang Gradle.

2. build.gradle

Mari asumsikan bahwa kita baru saja membuat proyek Java baru dengan menjalankan gradle init –type java-application . Ini akan meninggalkan kita dengan proyek baru dengan direktori dan struktur file berikut:

build.gradle gradle wrapper gradle-wrapper.jar gradle-wrapper.properties gradlew gradlew.bat settings.gradle src main java App.java test java AppTest.java

Kami dapat menganggap file build.gradle sebagai jantung atau otak proyek. File yang dihasilkan untuk contoh kami terlihat seperti ini:

plugins { id 'java' id 'application' } mainClassName = 'App' dependencies { compile 'com.google.guava:guava:23.0' testCompile 'junit:junit:4.12' } repositories { jcenter() }

Ini terdiri dari kode Groovy, atau lebih tepatnya, DSL berbasis Groovy (bahasa khusus domain) untuk menjelaskan build. Kita dapat mendefinisikan dependensi di sini dan juga menambahkan hal-hal seperti repositori Maven yang digunakan untuk resolusi dependensi.

Blok penyusun dasar Gradle adalah proyek dan tugas. Dalam kasus ini, karena plugin java diterapkan, semua tugas yang diperlukan untuk membangun proyek Java ditentukan secara implisit. Beberapa dari tugas tersebut adalah assemble , check , build , jar , javadoc , clean dan banyak lagi.

Tugas-tugas ini juga disiapkan sedemikian rupa, sehingga mendeskripsikan grafik dependensi yang berguna untuk proyek Java, yang berarti secara umum cukup mengeksekusi tugas build dan Gradle (serta plugin Java) akan memastikan, bahwa semua tugas yang diperlukan sudah dijalankan .

Jika kita membutuhkan tugas khusus tambahan, seperti, misalnya, membuat image Docker, itu juga akan masuk ke file build.gradle . Definisi tugas yang paling mudah terlihat seperti ini:

task hello { doLast { println 'Hello Baeldung!' } }

Kita bisa menjalankan tugas dengan menetapkannya sebagai argumen untuk Gradle CLI seperti ini:

$ gradle -q hello Hello Baeldung!

Ini tidak akan berguna, tetapi cetak “Halo Baeldung!” tentu saja.

Dalam kasus build multi-proyek, kami mungkin memiliki beberapa file build.gradle berbeda , satu untuk setiap proyek.

File build.gradle dijalankan terhadap instance Project , dengan satu instance Project dibuat per subproyek. Tugas di atas, yang dapat ditentukan dalam file build.gradle , berada di dalam instance Project sebagai bagian dari kumpulan objek Task . Tugas itu sendiri terdiri dari beberapa tindakan sebagai daftar yang diurutkan.

Dalam contoh kita sebelumnya, kita telah menambahkan penutupan Groovy untuk mencetak “Halo Baeldung!” ke akhir daftar ini, dengan memanggil doLast (Closure action) pada objek hello Task . Selama menjalankan Task , Gradle menjalankan setiap Actions -nya secara berurutan, dengan memanggil metode Action.execute (T) .

3. setting.gradle

Gradle juga menghasilkan file settings.gradle :

rootProject.name = 'gradle-example'

File settings.gradle juga merupakan skrip Groovy.

Berbeda dengan file build.gradle , hanya satu file settings.gradle yang dijalankan per build Gradle. Kita dapat menggunakannya untuk menentukan proyek dari sebuah pembangunan multi-proyek.

Selain itu, kami juga dapat mendaftarkan kode sebagai bagian dari hook siklus hidup yang berbeda dari sebuah build.

Framework ini memerlukan keberadaan settings.gradle dalam build multi-project, sementara itu opsional untuk build satu project.

File ini digunakan setelah membuat instance Settings dari build, dengan menjalankan file tersebut dan mengkonfigurasinya. Ini berarti kami mendefinisikan subproyek di file settings.gradle kami seperti ini:

include 'foo', 'bar'

dan Gradle memanggil metode void include (String… projectPaths) pada instance Settings saat membuat build.

4. gradle.properties

Gradle tidak membuat file gradle.properties secara default. Itu bisa berada di lokasi yang berbeda, misalnya di direktori akar proyek, di dalam GRADLE_USER_HOME atau di lokasi yang ditentukan oleh panji baris perintah -Dgradle.user.home .

File ini terdiri dari pasangan nilai kunci. Kita dapat menggunakannya untuk mengonfigurasi perilaku kerangka itu sendiri dan ini merupakan alternatif untuk menggunakan tanda baris perintah untuk konfigurasi.

Contoh kunci yang mungkin adalah:

  • org.gradle.caching = (benar, salah)
  • org.gradle.daemon = (benar, salah)
  • org.gradle.parallel = (benar, salah)
  • org.gradle.logging.level = (diam, peringatkan, siklus hidup, info, debug)

Selain itu, Anda dapat menggunakan file ini untuk menambahkan properti secara langsung ke objek Project , misalnya properti dengan namespace-nya: org.gradle.project.property_to_set

Kasus penggunaan lainnya adalah menentukan parameter JVM seperti ini:

org.gradle.jvmargs=-Xmx2g -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Harap dicatat bahwa itu perlu meluncurkan proses JVM untuk mengurai file gradle.properties . Ini berarti parameter JVM ini hanya berpengaruh pada proses JVM yang diluncurkan secara terpisah.

5. Singkatnya Build in a

Kita bisa meringkas siklus hidup umum build Gradle sebagai berikut, dengan asumsi kita tidak menjalankannya sebagai daemon:

  • Ini diluncurkan sebagai proses JVM baru
  • Ini mengurai file gradle.properties dan mengonfigurasi Gradle yang sesuai
  • Selanjutnya, ini membuat instance Pengaturan untuk build
  • Kemudian, ia mengevaluasi file settings.gradle terhadap objek Pengaturan
  • Ini membuat hierarki Proyek , berdasarkan objek Pengaturan yang dikonfigurasi
  • Akhirnya, ia mengeksekusi setiap file build.gradle terhadap proyeknya

6. Kesimpulan

Kita telah melihat, bagaimana file konfigurasi Gradle memenuhi berbagai tujuan pengembangan. Kita dapat menggunakannya untuk mengonfigurasi build Gradle serta Gradle itu sendiri, berdasarkan kebutuhan proyek kita.