Çok Modüllü Maven — common'ı Değiştirdim, Neyi Derlemeliyim?
Önce şunu oku: CI Pipeline — Geri Bildirim Neden Bu Kadar Geç Geliyor?
30 saniyede özet
Yalnızca değişen modülü derleyen build yeşil kalır ama değişikliği kullanan modülleri hiç denemez. -am bağımlı olunanları, -amd bağımlı olanları ekler; kütüphane sürümleri tek yerde, dependencyManagement'ta tutulur.
Bir lokantada şef ana sosun tarifini değiştirdi ve sosu tattı: güzel. Akşam o sosla yapılan makarna tuzlu çıktı. Sosu tatmak yetmemişti; sosu kullanan yemekleri de tatmak gerekiyordu.
-
Bayt: common'da para hesaplayan metodu değiştirdim. Sadece common'ı derledim, yeşil!
-
Sen: Ertesi sabah report-app'in build'i kırmızı. O metodu eski hâliyle çağırıyormuş.
-
Bayt: Ama build yeşildi! report-app'e hiç dokunmadım ki.
-
Bayt: Dokunmadın, ama o seni kullanıyor. Onu da derlemek gerekiyordu.
Reactor modülleri sırayla kurar
Çok modüllü bir projede Maven reactorÇok modüllü bir Maven projesinde modülleri bağımlılık sırasına dizip tek komutla kuran mekanizma. Önce kütüphaneler, sonra onları kullananlar kurulur.Sözlükte gör →, modülleri bağımlılık sırasına dizer: önce kütüphaneler, sonra onları kullananlar. mvn verify hepsini sırayla kurar.
Büyük projede hepsini kurmak uzun sürer. Bu yüzden -pl ile yalnızca seçilen modül kurulabilir. Asıl soru, seçilen modülün yanına başka neyin ekleneceğidir.
Kafam karıştı, daha basit anlat
Reactor modülleri sırayla kurar. -pl ile bir modül seçersin; geri kalanı sen eklersin.
Çok modüllü bir Maven projesinde mvn verify modülleri hangi sırayla kurar?
mvn -pl common verify ne kurar?
-am mi, -amd mi?
common değişti. Jenkins mvn -pl common -am verify koşuyor. common'ı kullanan report-app derlenir mi? Cevabı göster
Derlenmez. -am (also make) common’ın bağımlı olduklarını ekler; common’ın bağımlılığı yok. Onu kullanan report-app’i ekleyen -amd (also make dependents) olurdu.
Adım adım oku
- Ana sosun tarifi değişti.
- Yalnızca sos tadıldı: güzel.
- Sosla yapılan makarna tuzlu.
- Sosu kullanan yemekleri de tat.
İki bayrak iki ayrı yöne bakar. -am yukarıya, değişen modülün kullandıklarına bakar; -amd aşağıya, onu kullananlara bakar.
Değişikliği doğrulamak için aşağıya bakmak gerekir: -amd. İkisini birlikte vermek en güvenlisidir, çünkü onu kullananların ihtiyaç duyduğu diğer modüller de aynı build’de kurulur.
Kafam karıştı, daha basit anlat
-am kullandıklarını, -amd kullananları ekler. Değişikliği -amd doğrular.
-am (also make) ve -amd (also make dependents) arasındaki fark nedir?
common'daki bir metodun imzası değişti. Değişikliğin kimseyi kırmadığını doğrulamak için hangi komut gerekir?
Aynı kütüphane, iki sürüm
Bir modül Jackson’ın bir sürümünü, başka bir modül bir geçişli bağımlılıkSenin eklemediğin, eklediğin bir kütüphanenin kendi bağımlılığı olarak gelen kütüphane. Sürümünü çoğu zaman sen seçmezsin.Sözlükte gör → üzerinden başka bir sürümünü çekebilir. Maven ağaçta en yakın olanı seçer. Derleme geçer, hata çalışırken NoSuchMethodError olarak çıkar.
Çözüm, sürümü ana POM’daki dependencyManagement içinde bir kez yazmaktır. Birbirine bağlı kütüphane ailesi için bir BOMBill of Materials: birbirine bağlı kütüphane ailesinin uyumlu sürümlerini tek bir POM'da toplayan liste. dependencyManagement içine import edilir.Sözlükte gör → içe aktarılır; o ailenin bütün sürümleri birlikte sabitlenir.
Kafam karıştı, daha basit anlat
Kütüphane sürümünü ana POM’da bir kez yaz; modüller sürüm yazmasın.
İki modül Jackson'ın farklı sürümlerini çekiyor; uygulama çalışırken NoSuchMethodError veriyor. Kalıcı çözüm?
Kendin gör
Bir modül değişti: reactor neyi derliyor?
Tohum 259775- common · değişti… sırada
- ops-tool— derlenmeyecek
- pricing— derlenmeyecek
- report-app · değişeni kullanıyor— derlenmeyecek
- trading-app— derlenmeyecek
Plan: common · kurulan: 0/1
Şu an ne oldu?
Reactor 1 modül kuracak
common
Görevler0/2
Build yeşil yansın, ama kırık modül yayına gitsinaçık
İpucu
Yalnızca değişen modülü derle.
common değişsin; kırılmayı hepsini derlemeden yakalaaçık
İpucu
Ona bağımlı olanları da derle.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Yalnızca common derlendi, build yeşil. common’ı kullanan report-app hiç derlenmedi.
- Komutu -am yap. Yine tek modül: common’ın bağımlı olduğu bir şey yok.
- Komutu -amd yap. report-app derlendi ve kırıldı; ops-tool’a hiç dokunulmadı.
- Değişen modülü pricing yap. Bu kez kırılan trading-app; onu da yalnızca -amd yakalar.
Simülatörde common değişti ve -amd seçildi. Neden ops-tool hiç derlenmedi?
Tuzaklar
Eski SNAPSHOT. Reactor’a girmeyen bir modül, yerel depodaki (~/.m2) belki geçen haftadan kalmış kopyadan gelir. Değişen modülü -am -amd ile kur ki onu kullananlar bugünkü kodla derlensin.
Yalnızca değişen dosyalara bakmak. Jenkins’te git diff ile değişen modülleri bulmak iyi bir fikir. Bulduğun listeye -amd eklemezsen, kullananları yine kaçırırsın.
Baştan başlamak. Uzun bir build ortada kırıldıysa, -rf :modül ile kırılan modülden devam edebilirsin. Düzelttikten sonra bir kez de baştan sona koştur.
Kafam karıştı, daha basit anlat
-am ve -amd’yi birlikte ver. Değişen modül listesine kullananları da ekle.
Jenkins yalnızca pricing'i -pl pricing -amd ile kuruyor. trading-app, common'ın hangi kopyasıyla derlenir?
Aşağıda bir trading platformunun ana POM’u ve yalnızca değişen modülleri kuran Jenkins pipeline’ı var.
Derinleş · Trading platformu: sürümler tek yerde, build yalnızca etkilenenleri kurar 3 dosya · ~94 satır · ilk okumada atlayabilirsin
Kendini sına
-am, değişen modülü kullanan modülleri build'e ekler.
Build yeşil yandı, ertesi gün report-app derlenmedi. En olası neden?
Aklında kalacak üç şey
- 1 Bir modülü değiştirdiğinde, onu kullanan modüller de derlenmeli. Yalnızca değişen modülü derleyen build yeşil kalır, kırılma yayında çıkar.
- 2 -am değişen modülün bağımlı olduklarını, -amd ona bağımlı olanları ekler. Değişikliği doğrulayan -amd'dir; ikisi birlikte en güvenli seçimdir.
- 3 Aynı kütüphanenin sürümü ana POM'daki dependencyManagement'ta bir kez yazılır. Yoksa her modül başka bir sürümle derlenir ve hata çalışırken çıkar.