Gradle Gerçekten Maven'den Daha mı İyi? - Son Kararım

İlginç olduğunu düşündüğüm teknik içerikli tweetler atıyorum ama en çok ilgiyi çekenler komik tweetler oluyor. Mart ayında JavaLand konferansına katıldım, Gradle standına rastladım ve şu cevheri buldum:

Elbette bir noktada bir hayran konuyu ele geçirdi ve Gradle'ın sözde üstünlüğünü iddia etti. Bu yazıda, aynı "mantık"ı defalarca çürütmek yerine, insanları bu noktaya yönlendirebilmek için kendi duruşuma biraz ışık tutmak istiyorum.

Bunu yönetmek için zamanda geriye gitmem gerekiyor. Yazılım geliştirme hızla değişen bir alandır ve anlayışımızın çoğu kişisel deneyime dayanmaktadır. İşte benimki.

İlk yapım aracım: Ant

Java'da geliştirmeye 2002'de başladım. O zamanlar herhangi bir derleme aracı yoktu: IDE aracılığıyla derleyip derliyorduk. Bilginiz olsun, ilk olarak Java için Visual Age'i kullandım; daha sonra Borland JBuilder'a taşındım.

Bir IDE ile oluşturmanın büyük bir sorunu vardır: Her geliştiricinin özel ayarları vardır, bu nedenle yapıt oluşturma, geliştirici-makine kombinasyonuna bağlıdır.

Tekrarlanamayan yapılar asırlık bir sorundur. Tekrarlanabilir yapılarla ilgili ilk deneyimim Apache Ant:

Apache Ant, görevi, derleme dosyalarında tanımlanan süreçleri birbirine bağlı hedefler ve uzantı noktaları olarak yürütmek olan bir Java kitaplığı ve komut satırı aracıdır. Ant'ın bilinen ana kullanımı Java uygulamalarının oluşturulmasıdır. Ant, Java uygulamalarını derlemeye, birleştirmeye, test etmeye ve çalıştırmaya olanak tanıyan bir dizi yerleşik görev sağlar. Ant ayrıca C veya C++ uygulamaları gibi Java dışı uygulamalar oluşturmak için de etkili bir şekilde kullanılabilir. Daha genel olarak Ant, hedefler ve görevler açısından tanımlanabilecek her türlü süreci yönlendirmek için kullanılabilir.

-- https://ant.apache.org/

Karınca üç ana soyutlamaya dayanmaktadır:

• Görev atomik bir iş birimidir; örneğin Java dosyalarını derlemek için javac , Web Arşivi oluşturmak için war vb. Ant, kullanıma hazır pek çok görev sağlar ancak özel görevlerin eklenmesine de izin verir.
• Hedef, görevlerin bir listesidir.
• Derlemeye bağlı olarak paket gibi görevler arasındaki bağımlılıkları tanımlayabilirsiniz. Bu bakımdan Ant'ı bir iş akışı yürütme motoru olarak görebilirsiniz.

Kısa sürede Ant'ta "akıcı" oldum. Danışman olarak şirketten şirkete, projeden projeye gittim. Başlangıçta çoğunlukla Ant kurulumu yapıyordum ancak zamanla Ant yaygınlaştı ve mevcut Ant kurulumlarıyla karşılaştım. Projelerimde tutarlıydım ama diğer projeler birbirinden çok farklıydı.

Her seferinde yeni bir projeye vardığınızda, özel yapıyı anlamak için Ant kurulumunu dikkatlice okumak zorundaydınız. Üstelik her projenin yapısı farklıydı. Bazıları kaynaklarını src içine, bazıları sources , bazıları iç içe geçmiş bir yapıya vb. koyar.

Bir zamanlar bir organizasyonun proje ihtiyaçlarının tamamını karşılamaya çalışan genel bir derleme dosyasını hatırlıyorum. 2.000'den fazla XML satırında 80'den fazla hedef tanımladı. Yardımla nasıl kullanılacağını anlamak çok az zamanımı aldı ve projeleri bozmadan ince ayar yapabilmek daha da fazla zaman aldı.

İkinci yapım aracım: Maven

Yukarıdaki proje beni çok düşündürdü. Bakımcılar zaten Ant'ın sınırlarını zorlamış olduğundan durumu iyileştirmek istedim. O zamanlar arkadaşım Freddy Mallet (Sonar'la ünlü) ile çalışıyordum. Konuştuk ve beni Maven'a yönlendirdi. Bir zamanlar Maven ile bir proje yapmıştım ama daha önce başka deneyimim yoktu. Belgeleri saatlerce inceledim ve Freddy'nin gözetimi altında deneme yanılma yoluyla tüm Ant derleme dosyasını basit bir ana POM'a taşıdım.

Ant'ta her projedeki her şeyi tanımlamanız gerekir. Örneğin Ant, derleme için Java dosyalarının konumunu yapılandırmayı gerektirir; Maven bunların src/main/java altında olduğunu varsayar, ancak bunu geçersiz kılmak mümkündür. Maven , Konfigürasyon Üzerindeki Konvansiyon yaklaşımıyla Java derleme alanında devrim yarattı. Günümüzde pek çok yazılım varsayılan olarak hassas konfigürasyon sunmaktadır.

Benim gibi projeden projeye giden geliştiriciler için bu, yeni bir projeye katılırken çok daha az bilişsel yük olacağı anlamına geliyor. Java kaynaklarının src/main/java altında bulunmasını bekliyorum. Maven sözleşmeleri proje yapısının ötesinde de devam ediyor. Ayrıca, birim ve entegrasyon testleri yoluyla derlemeden yapıtın uzak bir kayıt defterine yüklenmesine kadar projenin yaşam döngüsünü de tanımlarlar.

Son olarak, genç geliştiriciler bundan habersiz olma eğilimindedir, ancak Maven bağımlılık yönetimi terimini tanımladı. Değişmez bağımlılıkların indirilebileceği ve yapıtların buraya aktarılabileceği yapı kayıtları fikri ortaya atıldı. Bu tarihten önce her projenin bağımlılıkları kendi özel deposunda saklaması gerekiyordu.

Bilginiz olsun, yukarıda bahsedilen projede birkaç depolanmış bağımlılık vardı. Ant'tan Maven'e geçiş yaptığımda tam bağımlılık sürümünü bulmam gerekiyordu. Çoğu için bu, dosya adında veya JAR'ın bildiriminde olduğu gibi basitti. Ancak biri ek sınıflarla güncellendi.

Değişmezlik için bu kadar.

Maven'in daha sonraki tüm inşa araçları üzerinde derin bir etkisi vardı: kendilerini Maven'e referansla tanımladılar.

Benim yapım aracım yok: Gradle

Gradle'ın öncelikli iddiası Maven'in eksikliklerini veya en azından onun bu şekilde algıladığı şeyleri düzeltmekti. Maven suçlamalardan muaf olmasa da Gradle, en önemli sorunun esneklik eksikliği olduğunu varsaydı. Bu şaşırtıcı bir varsayım çünkü Maven'in Ant'a göre geliştirdiği şey tam olarak buydu. Maven projeleri benzer yapılara sahiptir ve aynı yaşam döngüsünü kullanır: Etkide en az sürpriz ilkesi . Tersine, Gradle, yaşam döngüsü de dahil olmak üzere neredeyse her yapı yönünün özelleştirilmesine olanak tanır.

Esneklik argümanıyla yüzleşmeden önce, Maven'in daha sonra uyguladığı iki harika orijinal Gradle özelliğini kabul etmeme izin verin: Gradle arka plan programı ve Gradle sarmalayıcı.

Maven ve Gradle, JVM'de çalışan Java uygulamalarıdır. JVM'yi başlatmak zaman ve kaynak açısından pahalıdır. Avantajı, uzun süre çalışan JVM'nin JIT-ed kodunu zaman içinde optimize etmesidir. Kısa vadeli görevler için, JVM başlangıç süresini hesaba katarsanız faydası sıfırdır ve hatta zararlıdır. Gradle, Gradle arka plan programını ortaya çıkardı. Gradle'ı çalıştırdığınızda çalışan bir arka plan programı arayacaktır. Aksi takdirde yeni bir başlangıç yapacaktır. Komut satırı uygulaması her şeyi arka plan programına devredecektir. Adından da anlaşılacağı gibi, komut satırı bittiğinde arka plan programı durmaz. Arka plan programı JVM'nin avantajlarından yararlanır.

Muhtemelen uygulamanız mevcut derleme araçlarınızdan daha uzun süre dayanacaktır. Bundan beş yıl sonra bir hatayı düzeltmeniz gerektiğinde, ancak projenin oluşturma aracının çevrimiçi olarak mevcut olmadığını fark ettiğinizde ne olur? Gradle paketinin arkasındaki fikir, projeyle birlikte tam Gradle sürümünü ve tam sürümü İnternet üzerinden indirmek için yeterli kodu tutmaktır. Bir yan etki olarak geliştiricilerin Gradle'ı yerel olarak yüklemelerine gerek yoktur; hepsi aynı sürümü kullanıyor ve herhangi bir tutarsızlıktan kaçınılıyor.

Gradle'ın esnekliğinin çürütülmesi

Gradle, Maven'in entegre ettiği yukarıdaki iki harika özelliği getirerek rekabetin iyi olduğunu kanıtladı. Buna rağmen hala Gradle'ın hiçbir faydasını göremiyorum.

Duygusal tarafı bir kenara itmeye çalışacağım. Gradle pazarlaması başlangıçta Maven'i mümkün olan her durumda küçümsemeye çalıştı, çılgın karşılaştırma çizelgeleri yayınladı ve iletişimde genellikle çok agresifti. Diyelim ki bu aşama, pazarda kendine yer bulmaya çalışan genç bir şirket için kabul edilebilir olandan çok daha uzun sürdü. Gradle'ın yaklaşımının oldukça Oedipvari olduğunu söyleyebiliriz: Maven "babasını" öldürmeye çalışmak. Sonunda, bunca yıldan sonra, görünüşe göre aklı başına geldi ve artık "Maven'i seviyor."

Maven devralmadan önce her Ant projesinin geçici olduğunu unutmayın. Maven buna bir son verdi. Dünya Vahşi Batı'sına özel projelerin yasasını getirdi. Yasalara katılmayabilirsiniz ama yine de yasa budur ve herkesin buna uyması gerekir. Maven standartları o kadar yerleşiktir ki, örneğin kaynak konumu gibi bazı parametreleri geçersiz kılmak mümkün olsa da, hiç kimse bunu yapmaz.

Gradle'ın esnekliğinin iki belirtisini yaşadım. Çok daha fazlasının var olduğundan şüpheleniyorum.

Özel yaşam döngüsü aşamaları

Maven, entegrasyon testini sırayla yürütülen dört aşamada yönetir:

1. pre-integration-test : testlerin ihtiyaç duyduğu her şeyi ayarlayın
2. integration-test : testleri yürütün
3. post-integration-test : varsa kaynakları temizleyin
4. verify : testlerin sonuçlarına göre hareket etmek

Her testin özel bir kurulum ve sökme mantığı olduğundan, ön ve son aşamaları hiç kullanmadım.

Öte yandan Gradle'ın hiçbir entegrasyon testi kavramı yoktur . Ancak Gradle hayranları, istediğiniz aşamaları ekleyebileceğinizi memnuniyetle açıklayacaklardır. Aslında Gradle, yaşam döngüsünün "özelleştirilmesine" olanak tanır: normal yaşam döngüsüne istediğiniz kadar fazla aşama ekleyebilirsiniz.

Bu tam bir karmaşa, çünkü her projenin hem gereken aşama sayısını hem de adlarını bulması gerekecek: integration-test , integration-tests , integration-testing , it (tembeller için), vb. Seçenekler sonsuzdur.

Kar tanesi sendromu

Maven her projeyi normal standart bir proje olarak ele alır. Özel ihtiyaçlarınız varsa bunun için bir eklenti yazmanız mümkündür. Maven eklentisi yazmak kesinlikle eğlenceli değil; dolayısıyla yalnızca gerekli olduğunda bir tane yazarsınız, yalnızca yasanın sizin için geçerli olmadığına karar verdiğiniz için değil.

Gradle, esneklik eksikliğinin bir sorun olduğunu iddia ediyor; dolayısıyla düzeltmek istiyor. Ben bunun tam tersini savunuyorum: Oluşturma aracımın esnekliğinin olmaması bir hata değil, bir özelliktir. Gradle yapıyı hacklemeyi kolaylaştırır. Dolayısıyla projesinin özel bir kar tanesi olduğunu ve kişiselleştirilmeyi hak ettiğini düşünen herkes bunu memnuniyetle yapacaktır. Gerçeklik kontrolü: nadiren böyle olur; öyle olduğunda, çerçeveler içindir, normal projeler için değil. Gradle savunucuları, kolay konfigürasyona izin verirken hala standartlar sunduğunu söylüyor. Meselenin özü, herhangi birinin isteğiyle değiştirilebiliyorsa bunun bir standart olmamasıdır.

Gradle, Android projeleri için fiili oluşturma aracıdır. Çalıştığım şirketlerden birinde birisi, Sonar'ı çalıştırmak ve ölçümleri dahili Sonar örneğine göndermek için Gradle yapısında özel Groovy kodu yazdı. O zamanlar kullanıma hazır bir Sonar eklentisi yoktu ya da işe yaramadığını varsayıyorum. Şimdiye kadar, çok iyi.

Başka bir ekip şirketin ikinci Android projesini oluşturduğunda, ilk projenin yapısını ve derleme dosyasını kopyalayıp yapıştırdılar. Şu anda yapılacak en akıllıca şey, Sonar'a özgü koddan dahili bir Gradle eklentisi oluşturmak olurdu. Ancak bunu yapmadılar çünkü Gradle yapıyı hacklemeyi çok kolaylaştırdı. Ve Gradle'dan nefret eden ben, eklentiyi oluşturma görevini üzerime aldım. En azından daha iyi bir geliştirici deneyimi olabilirdi. Kaliteli dokümantasyona sahip olmadığım ve türlenmemiş bir dil (Groovy) kullandığım için, ilerlemek üzere nesnelerin yapısını yazdırmak için konsolu kullandım.

Çözüm

Rekabet iyidir ve Gradle, Maven'in sarmalayıcı ve arka plan programını entegre ettiği yeni fikirler getirdi. Ancak Gradle, esnekliğin iyi olduğu önermesi üzerine inşa edilmiştir, ancak deneyimlerim bana bunun tersini gösterdi. Ant çok esnekti ve bir projeden diğerine geçmenin bilişsel yükü yüksekti.

Biz geliştiriciler insanız: projelerimizin diğerlerinden farklı olduğunu düşünmek isteriz. Çoğu zaman değildirler. Kişiselleştirme sadece egomuzu tatmin etmenin bir yoludur. Esnek oluşturma araçları, garantili olsun ya da olmasın bu tür özelleştirmeleri uygulamamıza olanak tanır.

Alakasız özelleştirmeler hiçbir fayda sağlamaz ve geliştirilmesi kolaydır ancak bakımı pahalıdır. Yazılım varlıklarını yönetmek sorumluluklarımın bir parçasıysa, oluşturma aracım için her zaman esneklik yerine istikrarı seçeceğim.

İlk olarak 6 Ağustos 2023'te A Java Geek'te yayınlandı