ÖNEMLİ : Kendim için aldığım notlar. Umarım size de bir faydası olur. Bu yazı Jendrik Johannes’in Gradle’ı Anlamak İsimli Youtube içeriklerinin bir çevirisidir ve yazarın izni alınarak paylaşılmaktadır. Amacım hem aldığım notları sizinle paylaşmak hem de bilmeyenler için Jendrik’i size tanıtmaktır. Jendrik’in Gradle ile ilgili çok değerli içeriklere sahip olduğunu düşünüyorum. Türkçe kaynağa destek olmak için bu çevirileri sizinle paylaşmak istedim. Aşağıdaki yazı Jendrik’in kendi cümleleri olup, sadece turuncu blok içerisinde öne çıkardığım notlar bana aittir. Referanslara ise sayfa sonundan ulaşabilirsiniz.
SIFIRDAN BİR GRADLE PROJESİ BAŞLATMAK - SETTINGS DOSYASI
Yeni bir gradle projesi oluşturmak için yapmamız gereken şey, ilk olarak boş bir klasör oluşturmak ve bu klasör içine ya settings.gradle dosyası ya da settings.gradle.kts dosyası yerleştirmektir. Bu bir gradle projesinin beyanı için yeterlidir.
Benim Notum: settings dosyası, her Gradle build’in giriş noktasıdır. 1
Bilmemiz ve hatırlamamız gereken 3 şey vardır.
1 - Gradle build’nizi adlandırın
1
rootProject.name = "my-project"
Benim Notum:
Bunun uzun yazımı şu şekildedir.
1
settings.rootProject.name = "root"
Birinci olarak rootProject.name özelliğini kullanarak projenize sabit bir isim vermelisiniz.
2 - Gradle için, build’inizin bağlı olabileceği bileşenlerin konumlarını tanımlamaktır
İkinci olarak, Gradle’ın, build’inizin bağlı olabileceği diğer bileşenleri arayabileceği konumları tanımlayabilirsiniz. Bunlar, maven central gibi binary depolar (repositories) veya gradle’ın talep üzerine bileşenler oluşturmak için kullanabileceği diğer gradle build’ler olabilir.
Build’nizin bağlı olabileceği temelde iki farklı şeyin olduğunun farkına varmak önemlidir.
2.1 - Kütüphaneler (libraries) için diğer build’lerin depoları (repositories) ve lokasyonları
İlk şey, üretim (production) kodunuzun ihtiyaç duyabileceği kütüphanelerdir. Örneğin bir apache commons kütüphanesi gibi. Buradaki depolarda (repositories) bulunan bileşenler ikili (binary) bileşenlerdir. Bu, zaten Gradle veya başka bir derleme aracı tarafından oluşturulmuş oldukları anlamına gelir. Yani derlenmiş haldedirler. Ancak, gerekirse Gradle, bir bileşeni kaynaktan (source) oluşturmaya da destek sağlar. Yani, includeBuild() ifadesini kullanarak Gradle’a başka bir yerde bir Gradle build olduğunu ve gerekirse bu bileşeni oluşturabileceğini söylemektir. Yalnız bu, maven central’da bulunan repolar gibi binary halde olmadığı için derlenmeye ihtihaç duyar.
1
2
3
4
5
6
7
8
rootProject.name = "my-project"
dependencyResolutionManagement {
repositories {
mavenCentral()
}
includeBuild("../my-other-project")
}
Benim Notum:
dependencyResolutionManagement: tüm projeler için build’deki bağımlılık çözümlemesinin yapılandırılmasına izin verir. Yani tek tek build.gradle veyahut build.gradle.kts içinde repositories{} aracılığıyla bağımlılık çözümlemesi yapmak yerine; örneğin;
build.gradle.kts
1
2
3
4
5
6
7
8
9
10
11
12
13
plugins {
`java-library`
}
repositories {
google()
mavenCentral()
}
dependencies {
implementation("com.google.guava:guava:32.1.2-jre")
testImplementation("junit:junit:4.13.2")
}
bütün projeler için aynı bağımlılık çözümlemesini settings.gradle veyahut settings.gradle.kts içinde dependencyResolutionManagement ile yapabiliriz. 2
settings.gradle.kts
1
2
3
4
5
dependencyResolutionManagement {
repositories {
mavenCentral()
}
}
Bir diğer bilinmesi gereken şey ise şudur: Varsayılan olarak, build.gradle(.kts) içindeki bir proje tarafından bildirilen depolar(repositories), settings.gradle(.kts)‘de bildirilen her şeyi geçersiz kılacaktır:
settings.gradle.kts
1
2
3
dependencyResolutionManagement {
repositoriesMode = RepositoriesMode.PREFER_PROJECT
}
Bu arada settings.gradle dosyanızda dependencyResolutionManagement bloğunuzdaki repository’leri şu şekilde de deklare edebilirsiniz.
settings.gradle.kts
1
2
3
4
5
6
7
8
9
10
dependencyResolutionManagement {
repositories.mavenCentral()
repositories.google()
repositories.maven("https://location/my-repo"){
name = "my-repo"
credentials.username ="my-username"
credentials.password ="my-password"
}
includeBuild(".../my-other-project")
}
Dikkat ederseniz en sonuncu repository deklerasayonu maven’da bulunan custom bir repository’ye nasıl ulaşılacağın gösteriyor.
Benim Notum:
Dikkat etmişsinizdir belki, Gradle’daki repositories {} bloğunu, arka planda DependencyResolutionManagement interface’i içindeki repositories(Action<? super RepositoryHandler>) metodunu çağırmaktadır.
Gradle, Groovy veya Kotlin tabanlı bir DSL (domain-specific language) kullanır. Bu, Gradle’ın tanımlamaları daha sezgisel ve anlaşılır hale getiren bir dildir. Arka planda Gradle, DSL üzerinde yaptığınız her işlemi Java API‘sine dönüştürür. Bu dönüşüm, DSL’in sağladığı soyutlama katmanıdır ve bu soyutlama sayesinde, karmaşık API yapısını fark etmiyorsunuz ve repositories {} gibi basit ve sade yapılandırmalar yazabiliyorsunuz.
Şimdi, Gradle’ın nasıl çalıştığını daha iyi anlamak için şu mekanizmayı gözden geçirelim:
Kotlin’i Ele Alırsak;
repositories {}DSL Yapısı : Görünüşte basit olan bu yapı, aslında arka planda bir Action nesnesi olarak Java API’sine dönüştürülür. Yani, bu yapı DSL’nin sağladığı kolay bir kullanım şeklidir, ama Gradle bu ifadeyi Java tarafında nasıl kullanacağını biliyor.repositories(Action<? super RepositoryHandler>)Metodu : Bu metot, arka planda Gradle tarafından çağrılır. Burada önemli olan şey, Action arayüzünün Groovy veya Kotlin DSL’de yapılandırma bloklarına karşılık gelmesidir. Yani,Action<? super RepositoryHandler>, bir yapılandırma bloğunu temsil eder. Gradle’da her yapılandırma bloğu ({}), aslında bir Action olarak yorumlanır.
Dolayısıyla, yazdığınız şu yapı:
1
2
3
4
repositories {
google()
mavenCentral()
}
Arka planda şu yapıya çevrilir:
1
2
3
4
5
6
7
repositories(new Action<RepositoryHandler>() {
@Override
public void execute(RepositoryHandler repositories) {
repositories.google();
repositories.mavenCentral();
}
});
Bu yüzden, repositories {} bloğu aslında bir Action’dır ve repositories(Action<? super RepositoryHandler>) metoduna bu yapılandırma bloğu otomatik olarak geçirilir.
Action Arayüzü Nedir?
Action<T> bir fonksiyonel arayüzdür (yani functional interface’dir, hatırlayacağınız üzere functional interface tek bir soyut metota sahiptir.) ve execute(T t) isminde tek bir metod içerir. Groovy ve Kotlin DSL, bu Action arayüzünü kullanarak yapılandırma bloklarını yukarıdaki kodda olduğu gibi execute metodu içinde değerlendirir. Bu sayede repositories {} bloğunun içi, Action<RepositoryHandler> arayüzündeki execute metodunun içeriği haline gelir. Gradle, burada RepositoryHandler nesnesine çeşitli metotlar uygulanarak (google(), mavenCentral()) yapılandırmayı tanımlar.
Peki Neden Action Kullanılır?
Action arayüzü, build script içinde bir yapılandırmayı esnek ve okunabilir hale getirmek için kullanılır. Örneğin, {} içinde yazdığınız her şey, belirli bir nesne üzerinde çalıştırılan işlemler dizisi olarak değerlendirilir. Bu da DSL’in esnekliğini sağlar.
Groovy’i Ele Alırsak;
Bu arada Groovy dilinde, {} içine yazdığınız her şey aslında bir closure‘dır. Bu closure’lar, belirli bir bağlama (context) göre çalışır ve bu bağlamda işlem yapılır. Gradle DSL’deki birçok yapı, arka planda closure’ları alıp Action arayüzüne çevirir. Bu sayede, closure’lar Gradle DSL’deki nesnelere uygulanabilir ve yapılandırma yapılabilir.
Örneğin:
1
2
3
4
repositories {
google()
mavenCentral()
}
Bu Groovy DSL’deki closure yapısıdır. repositories bloğuna geçtiğiniz her şey, bir closure olarak işlenir ve bu closure Action‘a çevrilerek Java’da şu şekilde kullanılır:
1
2
3
4
5
6
7
repositories(new Action<RepositoryHandler>() {
@Override
public void execute(RepositoryHandler handler) {
handler.google();
handler.mavenCentral();
}
});
Bu sayede, closure’lar Gradle DSL’deki nesnelere uygulanabilir ve yapılandırma yapılabilir.
repositories {}bloğu, aslındarepositories(Action<? super RepositoryHandler>)metoduna geçilen bir closure gibi çalışır. Bu closure,RepositoryHandlerüzerinde çalıştırılan yapılandırmaları içerir.repositories.google()gibi doğrudan metot çağrıları ise,RepositoryHandlernesnesine bağlıdır verepositories(Action)içinde çalıştırılan metotların basitleştirilmiş hali olarak düşünülebilir.
Yani repositories {} bloğu daha geniş bir yapılandırma bloğu olup birden fazla işlem ve metodun bir arada çalıştırılmasına olanak tanır. Buna karşın repositories.google() gibi metot çağrıları, doğrudan bir RepositoryHandler nesnesine erişimi temsil eder.
4. Gradle’ın Çalışma Zamanı (Runtime) Yapısı
Gradle, çalıştırma zamanında build script’i okur ve bu script’teki DSL yapısını, Java’daki ilgili API’lere dönüştürür. Bu işlem, build script’iniz değerlendirilirken (evaluate) gerçekleşir. Yani, bir build script’in okunduğu anda şu işlemler olur:
- Script okunur ve Groovy/Kotlin DSL ile tanımlanmış yapı blokları tespit edilir.
- Yapı blokları (repositories {}) gibi,
Actionnesneleri olarak değerlendirilir. - Action’lar ilgili metotlara geçirilir (örneğin,
repositories(Action)), burada blok içindeki her işlem,RepositoryHandlerüzerinde çalıştırılır.
Bu sayede repositories {} gibi yapılar arka planda repositories(Action) gibi çalışır.
Sonuç Olarak:
Gradle’ın sunduğu DSL, Groovy veya Kotlin gibi dillerin esnekliği sayesinde, metotların daha anlaşılır ve sade hale getirilmiş versiyonlarını yazmamızı sağlar. Ancak arka planda, her yapılandırma bloğu bir Java API’sine dönüşür ve bu dönüşüm sırasında Action arayüzü kullanılarak ilgili işlemler gerçekleştirilir. İşte bu nedenle repositories {} ile repositories(Action) metodunun işleyişi arasında doğrudan bir bağlantı vardır.
2.2 - Gradle eklentileri (plugin) için diğer build’lerin depoları (repositories) ve lokasyonları
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
rootProject.name = "my-project"
pluginManagement{
repositories {
gradlePluginPortal() // Artifact Repository
google() // Maven Artifact Repository
}
includeBuild("../my-build-logic")
}
dependencyResolutionManagement {
repositories {
mavenCentral()
}
includeBuild("../my-other-project")
}
İkincisi ise gradle’ın kendisini genişleten eklentilerdir(plugin). Bunlar genellikle gradle eklenti(plugin) portalında bulunur. Ancak diğer binary(ikili) depolar aracılığıyla da sağlanabilir. Bunun yanı sıra, eklentileri diğer build’larda yerel olarak da tanımlayabilirsiniz.
Benim Notum:
Az önce bahsettiğimiz üzere Gradle’ın kendisi de Gradle eklentileri (plugins) ile genişletilebilir. Bunlar da aslında belirli Gradle arayüzlerini (interfaces) uygulayan (yani implement eden) jarlar veya Java kodlarıdır. Bu yüzden Gradle’ı genişletme mekanizması, geliştirdiğiniz yazılıma kütüphaneler eklemekle oldukça benzerdir. Bunun için settings dosyasında pluginManagement {} bloğu vardır. Bu bloğun içinde dependencyResolutionManagement {} bloğundaki ile aynı yapı bulunur. Gradle’ın ek eklentiler keşfetmesi için depolar (repositories) ekleyebilirsiniz. Çoğu eklentinin bulunduğu yer Gradle Plugin Portal‘dır. Ancak eklentiler (plugins) Maven Central‘da da barındırılabilir. Ya da Android için, Google Deposu’nda bulunabilirler. Veya bu depoları yansıtıyorsanız (mirror) ya da kendi Gradle eklentilerinizi bir depoya yayımlıyorsanız (publish ediyorsanız), burada özel depolar da ekleyebilirsiniz. Bu yüzden includeBuild() ifadesi de vardır. Yani yerel olarak Gradle eklentileri geliştirip burada include edebilirsiniz. Bu, iyi yapılandırılmış bir Gradle build setup’ı için çok önemli bir mekanizmadır.
bu arada repositories eklemenin bir diğer yolu dependencyResolutionManagement de olduğu gibi aşağıdaki yöntemdir.
1
2
3
4
5
6
7
8
9
10
11
pluginManagement{
repositories.gradlePluginPortal()
repositories.mavenCentral()
repositories.google()
repositories.maven("https://location/my-repo"){
name = "my-repo"
credentials.username ="my-username"
credentials.password ="my-password"
}
includeBuild("gradle/plugins")
}
Benim Notum:
Burada pluginManagement{} kod bloğu içindeki includeBuild() 3, işaret edilen path’deki plugin build’ini composite build’a dahil eder. Benzer şekilde dependencyResolutionManagement kod bloğu içindeki includeBuild() 4 ise, işaret edilen path’deki build’i composite build’a dahil eder.
Bunun yanı sıra, “pluginManagement{}” bloğu yalnızca “settings.gradle(.kts)” dosyasında görünebilir; burada, dosyadaki veya bir “Initialization Script”‘deki ilk blok olmalıdır. 5
Bu arada Gradle topluluğunun çok projeli (multi-project) build yapıları için iki standardı vardır: bunlardan biri ìncludeBuild kullanan composite build, diğeri ise buildSrc kullanan Multi-Project Build‘lerdir.6
Multi-Project Build‘ler (yani buildSrc), projeleri birçok modülle düzenlemenize, bu modüller arasındaki bağlılıkları bağlamanıza ve bunlar arasında ortak yapı mantığını (build logic) kolayca paylaşmanıza olanak tanır. included builds olarak da adlandırılan Composite Build‘ler, build’ler (alt projeler değil) arasında mantığı (logic) paylaşmak veya paylaşılan yapı mantığına (build logic) erişimi izole etmek (yani, convention plugin’ler) için en iyisidir.
Bu arada Gradle, modülleri alt projeler (sub-projects) olarak ifade eder.
Jendrik’e göre pluginManagement & dependencyResolutionManagement Blokları Arasındaki Fark?
Bu, Gradle’ın Java uygulamaları oluşturmak için kullanılmasının yanı sıra aynı zamanda bir Java uygulaması (yazılım oluşturmak için bir uygulama) olmasından kaynaklanan yaygın bir kafa karışıklığıdır.
- “dependencyResolutionManagement repositories” öncelikli endişeniz olmalıdır. Bu, uygulamanıza entegre etmek istediğiniz bileşenlere hizmet veren repo’ları bildirmek içindir. Örneğin, “mavenCentral()” tarafından sunulan “org.Apache.commons:commons-lang3:3.14.0” kullanmak istiyorsunuz. Başka bir deyişle burası, yazılımınızın bağımlılıklarının çözümlenmesini yönetmekle ilgilidir.
- “pluginManagement repositories” yalnızca Gradle’ın kendisini genişletmek istiyorsanız gereklidir. Harici Gradle eklentilerini yönetmekle ilgilidir. Yalnızca Gradle ile birlikte gelen java-library gibi Gradle core eklentilerini kullanıyorsanız buna ihtiyacınız yoktur. Ancak “gradlePluginPortal()” veya “google()” gibi depolar tarafından sunulan “id(“com.autonomousapps.dependency-analiz”) version “1.30.0” “ gibi harici bir eklenti kullanmak istiyorsanız bunu kullanabilirsiniz.
Gradle eklentileri Jar dosyalarıdır (çünkü Gradle genişletilebilir bir Java uygulamasıdır). Dolayısıyla dışarıdan bakıldığında, “normal” Java kütüphaneleri (Java libraries) (commons-lang gibi) ve Gradle eklentileri (dependency-analysis gibi) benzer türde artifektlerdir. Ve bir Java kütüphanesi, Java’da da uygulandığı (implement edildiği için) için Gradle eklentisinin parçası olabilir. Bu nedenle DependencyResolutionManagement ve PluginManagement’te tanımladığınız şeyler örtüşebilir (ancak örtüşmek zorunda değildir).
3 - Build’in yapısı - alt projeler (subprojects)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
rootProject.name = "my-project"
pluginManagement{
repositories {
gradlePluginPortal() // Artifact Repository
google() // Maven Artifact Repository
}
includeBuild("../my-build-logic")
}
dependencyResolutionManagement {
repositories {
mavenCentral()
}
includeBuild("../my-other-project")
}
include("app")
include("business-model")
include("data-model")
Üçüncü şey ise, settings dosyasında tanımlayacağınız projenizin gerçek yapısıdır. Proje, subproject (alt proje) adı verilen projelerden oluşur. Bir alt projeyi include() deyimini kullanarak tanımlarsınız. Örneğimizde üç alt proje tanımlıyoruz. Biri veri modelimiz (data-model) için, biri iş mantığı (business-logic) için ve biri de uygulama kodu (app) için olacak.
Bu alt projeleri nasıl içerikle dolduracağımızı bir sonraki bölümün konusu olacak. Şimdi settings dosyasıyla ilgili bahsetmek istediğim iki şey daha var.
Benim Notum:
my-project klasörü ile aynı dizinde bulunan my-build-logic ve my-other-project isimli iki boş klasörü eklediğimizi görüyorsunuz. Bu klasörlere henüz bir şey yazmadık. Ama pluginManagement ve dependencyResolutionManagement kod blokları içinde, includeBuild("../my-build-logic") ve includeBuild("../my-other-project") deyimleri aracılığı ile bu projeleri my-project isimli gradle projesine dahil ettiğimizi görüyorsunuz. Dilerseniz şimdilik bu kısımları yorum satırı ekleyerek pasif hale getirebilirsiniz. O kısımları ileriki içeriklerde kodlayacağız.
3.1 - settings eklentilerini (plugin) kullanma
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
rootProject.name = "my-project"
pluginManagement{
repositories {
gradlePluginPortal() // Artifact Repository
google() // Maven Artifact Repository
}
includeBuild("../my-build-logic")
}
plugins{
id("..")
}
dependencyResolutionManagement {
repositories {
mavenCentral()
}
includeBuild("../my-other-project")
}
include("app")
include("business-model")
include("data-model")
İlk şey, ayarlar (settings) dosyasının bir plugins {} bloğuna sahip olabilmesidir. Burada, konfigürasyonu çeşitli build’ler arasında paylaşmak için settings plugins adı verilen eklentileri uygulayabilirsiniz. Gelecek içeriklerin birinde bu konuyu ayrıntılı olarak konuşacağız.
3.2 - settings dosyasında script kodu
İkinci şey ise Kotlin (veya Groovy) kullandığımız için Kotlin dilinin tüm gücüne burada sahip olmamızdır. Bunu belirli konfigürasyonları daha kullanışlı hale getirmek için kullanabiliriz. Örneğin, root (kök) klasörümüzün tüm alt klasörlerini (sub folders) döngü içerisinde tekrarlayabilir ve her birini bir alt proje olarak dahil edebiliriz, böylece settings dosyasında bunlardan ayrı ayrı bahsetmemize gerek kalmaz.
1
2
3
4
5
6
7
- include("app")
- include("business-model")
- include("data-model")
+ rootDir.listFiles().filter { it.isDirectory && !it.isHidden }.forEach {
+ include(it.name)
+ }
Benim Notum: Standard Settings properties
Settings nesnesi, settings script’inde standart bir properties kümesini ortaya çıkarır. Yukarıda bahsedilen rooDir bunlardan biridir. Aşağıdaki tabloda yaygın olarak kullanılan birkaç özellik listelenmiştir: 7
| Name | Description |
|---|---|
| buildCache | - The build cache configuration. |
| plugins | - The container of plugins that have been applied to the settings. |
| rootDir | - The root directory of the build. The root directory is the project directory of the root project. |
| rootProject | - The root project of the build. |
| settings | - Returns this settings object. |
Aşağıdaki tabloda yaygın olarak kullanılan birkaç metot listelenmiştir:
| Name | Description |
|---|---|
| include() | - Adds the given projects to the build. |
| includeBuild() | - Includes a build at the specified path to the composite build. |
Settings File Scripting Settings nesnesinde, buildWinizi yapılandırmak için kullanabileceğiniz daha birçok properties ve metot vardır. Birçok Gradle betiği tipik olarak kısa Groovy veya Kotlin sözdizimiyle yazılmasına rağmen, settings script’indeki her öğenin esasen Gradle API’sindeki “Settings” nesnesinde bir yöntem çağırdığını hatırlamak önemlidir:
1
include("app")
Aslında budur:
1
settings.include("app")
Ek olarak, Groovy ve Kotlin dillerinin tüm gücü kullanımınıza açıktır. Örneğin, alt projeler eklemek için birçok kez dahil etmek yerine, proje kök klasöründeki dizinlerin listesini yineleyebilir ve bunları otomatik olarak dahil edebilirsiniz:
1
2
3
rootDir.listFiles().filter { it.isDirectory && (new File(it, "build.gradle.kts").exists()) }.forEach {
include(it.name)
}
Not: Bu tür bir logic bir plugin’de geliştirilmelidir.
Benim Notum:
Gradle’a öncelikle yazılım projenizin yapısını tanımlayan bir araç olarak bakmak ve bunu Gradle’ın sunduğu DSL ile nasıl yapacağınızı öğrenmek yararlı olacaktır. Teknik olarak Gradle’ın DSL’i bir Java API‘sidir, dolayısıyla Kotlin, Groovy veya Java’nın kendisi gibi herhangi bir JVM tabanlı dil, potansiyel olarak bir yazılım projesini Gradle terimleriyle tanımlamak için kullanılabilir. Bunu kolaylaştırmak için Gradle, DSL’nin Kotlin versiyonunu ve DSL’nin Groovy versiyonunu sunuyor.
Settings (settings.gradle(.kts)) dosyası bulunduğunda, Gradle bir Settings nesnesi oluşturur. Settings nesnesinin amaçlarından biri, build’e dahil edilecek tüm projeleri bildirmenize izin vermektir. Gradle bir build için projeleri bir araya getirmeden önce, bir Settings örneği oluşturur ve settings dosyasını buna karşı yürütür.
settings script yürütülürken, Settings’i de yapılandırır. Bu nedenle, settings dosyası Settings nesnesini tanımlar. Bir Settings örneği ile bir settings.gradle(.kts) dosyası arasında bire bir yazışma (one-to-one correspondence) vardır.
Bununla birlikte, Settings nesnesi Gradle API‘sinin bir parçasıdır.
Benim Notum: Gradle wrapper nedir?
settings.gradle(.kts) çalıştığında dosyasını yüklediğimizde, IntelliJ’in bizim için bir sürü ekstra dosya eklediğini görebiliyoruz.
Bu, Gradle sarmalayıcı (Gradle wrapper) olarak bilinen bir araçtır. Dikkat ettiyseniz, bu sayede gradle’ı bilgisayarınızda bir yere kurmanıza gerek kalmadı. Gradle sarmalayıcı (Gradle wrapper), bizim için bunu halleden küçük bir araçtır (small tool). Bu aracı projenize ekleyebilir, hatta git versiyon kontrol sistemine commit edebilirsiniz. Böylece bu projeyi build etmek isteyen herkes otomatik olarak doğru Gradle versiyonunu alır ve herhangi bir şey yüklemesine gerek kalmaz.
Şekilden de görüleceği üzere, Gradle sarmalayıcıyı başlatmak için biri unix için, diğeri windows için olmak üzere iki başlatma script’inin olduğunu görüyoruz. Ve sonrasında, sarmalayıcının gerçek implementasyonu olan bir “jar” dosyası (gradle-wrapper.jar) ve sarmalayıcıyı yapılandırmak için bir “wrapper.properties” dosyası (yani gradle-wrapper.properties) vardır.
Eğer properties dosyasını açarsanız, Intellij’in gradle’ın son sürümünü seçtiğini görürsünüz. Başka bir sürüm kullanmak istiyorsanız buradan değiştirebilirsiniz.
gradle-wrapper.properties
1
2
3
4
5
6
7
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.4-bin.zip
networkTimeout=10000
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Benim Notum: Settings Script structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
pluginManagement { // 1
repositories {
gradlePluginPortal()
google()
}
}
plugins { //2
id("org.gradle.toolchains.fake") version "0.6.0"
}
rootProject.name = "root-project" //3
dependencyResolutionManagement { //4
repositories {
mavenCentral()
}
}
include("sub-project-a") //5
include("sub-project-b")
include("sub-project-c")
-
plugin’lerin lokasyonunu tanımlar “Settings” dosyası, isteğe bağlı olarak, “Gradle Plugin Portalı” gibi binary repolar veya “
includeBuild” kullanan diğer Gradle build’leri dahil olmak üzere projenizinpluginManagement” ile kullandığı pluginleri tanımlayabilir:1 2 3 4 5 6
pluginManagement { repositories { gradlePluginPortal() google() } }
Bu bloğa pluginleri ve plugin bağımlılığı çözümleme (plugin dependency resolution) stratejilerini de dahil edebilirsiniz.
-
plugin’leri uygular (apply).
Settings dosyası, isteğe bağlı olarak daha sonra uygulanabilecek pluginleri bildirebilir; ki bu da, birkaç build/alt proje (subprojects) arasında paylaşılan konfigürasyon ekleyebilir:
Settings’e uygulanan eklentiler yalnızca Settings nesnesini etkiler.
1 2 3
plugins { id("org.gradle.toolchains.fake") version "0.6.0" }
Bu genellikle tüm alt projelerin aynı plugin sürümünü kullanmasını sağlamak için kullanılır.
- Kök projenin(root project) adını tanımlar
Settings dosyası, rootProject.name özelliğini kullanarak proje adınızı tanımlar:
1
rootProject.name = "root-project"
Build başına yalnızca bir kök proje vardır.
-
build-wide repoları tanımlar.
Aslında 4. madde dışındakiler net bir şekilde izah ediliyor. “Settings” dosyası isteğe bağlı olarak projenizin dayandığı bileşenlerin konumlarını (ve bunların nasıl çözüleceği), örneğin Maven Central gibi binary repoları,
repositorieskullanarak ve diğer Gradle build’leriincludeBuildkullanarak tanımlayabilir:1 2 3 4 5
dependencyResolutionManagement { repositories { mavenCentral() } }
Bu bölüme sürüm kataloglarını da dahil edebilirsiniz.
-
build’e alt projeler ekler.
Settings dosyası,
includeifadesini kullanarak tüm alt projeleri ekleyerek projenin yapısını tanımlar:1 2 3
include("app") include("business-logic") include("data-model")
Detaylı bilgi için şu linki ziyaret edebilirsiniz.
Referanslar:
- 01 – The Settings File
- onepiece.Software
- Modern Gradle Fundamentals
- Jendrik’s mastodon account
- Jendrik’s github
- Jendrik Johannes’s youtube channel
- Logo
- Writing Build Scripts
- Update to work the new way
