Maven neden bu kadar kötü bir şöhrete sahip? [kapalı]


99

İnternette Maven'in ne kadar kötü olduğu hakkında çok fazla konuşma var. Birkaç yıldır Maven'in bazı özelliklerini kullanıyorum ve bence en önemli faydası bağımlılık yönetimi.

Maven dokümantasyonu yeterli değildir, ancak genellikle bir şeyi başarmam gerektiğinde bir kez çözerim ve sonra çalışır (örneğin kavanozları imzalamayı uyguladığımda). Maven'in harika olduğunu düşünmüyorum, ancak bazı sorunları çözer ki, onsuz gerçek bir acı olur.

Öyleyse, Maven neden bu kadar kötü bir şöhrete sahip ve gelecekte Maven ile ne tür sorunlar bekleyebilirim? Belki bilmediğim çok daha iyi alternatifler vardır? (Örneğin Ivy'ye hiç detaylı bakmadım.)

NOT: Bu, bir tartışmaya neden olma girişimi değildir. FUD'yi temizleme girişimidir.


29
Hiç kimsenin Maven hakkında kötü konuştuğunu duymadım. Maven ile Ant'tan çok daha verimli projeler buldum.
Taylor Leese

2
Taylor'a katılıyorum. Maven'i kullanmadım ama birçok insanın bundan övgüyle bahsettiğini duydum. Bu soru FUD'ye çok benziyor.
Matthew Flaschen

27
@Taylor, @Matthew, @Victor: Maven rantlarından bazılarını görmemiş olmanıza şaşırdım. Bu çok bölücü bir araçtır. Bu gerçek bir aşk ya da nefret meselesi. Bazı insanlar bağımlılık yönetimi zekasını severler ve bundan hoşlanmayanları almamakla suçlarlar ve bazıları sadece karmaşık dağıtılmış bağımlılıklarla ortaya çıkabilecek ve ortaya çıkabilecek sorunları görür ve bunun uğraşmaya değmeyeceğine karar verir.
Dan Dyer

8
Maven, KISS ilkesine saygı göstermez. Mvn clean install dışında bir şey yapmaya çalışın ve başınız belada. Karınca ile acı çekmeden istediğinizi yapabilirsiniz.
TraderJoeChicago

4
Bu sadece bir anekdot, ancak Maven'den Ant'a geçmek, artımlı derleme sürelerimizin ~ 15 saniyeden 2 dakikaya kadar çıkmasına neden oldu. Ekibimizde çok fazla Maven hayranı bulamazsınız.
Peter Bratton

Yanıtlar:


141

Yaklaşık altı ay önce mavenlere baktım. Yeni bir projeye başlıyorduk ve destekleyecek mirasımız yoktu. Bahsedilen:

  • Maven ya hep ya hiçtir. Ya da en azından belgelerden anlayabildiğim kadarıyla. Karınca yerine maven'i kolayca kullanamazsınız ve yavaş yavaş daha gelişmiş özellikleri benimseyemezsiniz.
  • Belgelere göre, Maven en çılgın hayallerinizi gerçeğe dönüştüren aşkın mutluluktur. Sadece aydınlanmadan önce 10 yıl boyunca kılavuz üzerinde meditasyon yapmalısınız.
  • Maven, oluşturma sürecinizi ağ bağlantınıza bağımlı hale getirir.
  • Maven'de gereksiz hata mesajları var. Karıncanın "Hedef x, y projesinde mevcut değil" ile mvn'nin "Geçersiz görev" çalıştırması "nı karşılaştırın: geçerli bir yaşam döngüsü aşaması veya eklenti biçiminde bir hedef belirtmelisiniz: hedef veya eklentiGroupId: pluginArtifactId: pluginVersion: hedef" Faydalı, daha fazla bilgi için -e ile mvn çalıştırmamı önerir, bu da aynı mesajı yazdıracağı ve ardından BuildFailureException için bir yığın izlemesi yazacağı anlamına gelir.

Maven'i sevmememin büyük bir kısmı Better Builds with Maven'den şu alıntıyla açıklanabilir:

Birisi Maven'in ne olduğunu bilmek istediğinde, genellikle “Maven tam olarak nedir?” Diye sorar ve kısa, sesli bir cevap beklerler. "Bu bir inşa aracı veya bir betikleme çerçevesi" Maven üçten fazla sıkıcı, ilham vermeyen kelimedir. Fikirlerin, standartların ve yazılımın bir birleşimidir ve Maven'in tanımını basitçe sindirilmiş ses parçalarına indirgemek imkansızdır. Devrimci fikirlerin kelimelerle aktarılması genellikle zordur.

Benim önerim: Fikirleri kelimelerle aktaramıyorsanız, konu hakkında bir kitap yazmaya kalkışmamalısınız çünkü telepatik olarak fikirleri özümsemeyeceğim.


134
Maven'i anlayanlar için açıklamaya gerek yok. Yapmayanlara açıklama yapmak mümkün değil.
Apocalisp

35
Madde işaretlerinden biri yanlış. -o - çevrimdışı mod, dolayısıyla hayır, oluşturma sürecinizi ağ bağlantınıza bağımlı hale getirmez.
MetroidFan2002

10
Ya hep ya hiç noktasına katılıyorum. Birçok insanın proje portföylerinin yarısını karınca ve yarısını maven'de tutmaya çalışırken çok fazla zaman harcadığını gördüm. Bir kez taahhütte bulunduktan sonra, dağıtımınızın her bölümünü dönüştürmek için çaba sarf etmeniz gerekir.
sal

14
@Apocalisp: Yani Maven'i anlayan tek kişi onu yazan kişiler mi?
Powerlord

5
Maven ya hep ya hiçtir. Bu doğru değil. Bağımlılık yönetimi için maven'i kullanabilirsiniz, isterseniz başka hiçbir şey yapamazsınız. Tüm yapmanız gereken, pom dosyanızı okumak ve tüm bağımlılıklarınızı içeren bir ANT sınıf yolu oluşturmak için Maven karınca görevlerini nasıl kullanacağınıza dair çalışan bir örnektir.
Jherico

109
  • Başlangıçtan itibaren size katı bir yapı uygular.
  • XML tabanlı olduğu için ANT kadar okunması zor.
  • Hata raporlaması belirsizdir ve işler ters gittiğinde sizi mahsur bırakır.
  • Belgeler zayıf.
  • Zor şeyleri kolaylaştırır, basit şeyleri zorlaştırır.
  • Her şeyi söyleyen bir yapı sistemine sahip olma noktasını ortadan kaldıran bir Maven inşa ortamını sürdürmek çok fazla zaman alır.
  • Maven'de bir hata bulduğunuzu ve yanlış bir şey yapılandırmadığınızı anlamak uzun zaman alıyor. Ve böcekler şaşırtıcı yerlerde var.
  • Çok şey vaat ediyor ama güzel ve baştan çıkarıcı ama duygusal olarak soğuk ve manipülatif bir aşık gibi size ihanet ediyor.

45
++ Zor şeyleri kolaylaştırır, basit şeyleri zorlaştırır. Çok doğru!
Martin K.

8
"Çok şey vaat ediyor ama size güzel ve baştan çıkarıcı ama duygusal olarak soğuk ve manipülatif bir aşık gibi ihanet ediyor." hahahaha ... kulağa çok benziyor "Balls of Fury" den o usta fong
cesar

8
Tekrar madde işareti 2: Neredeyse her zaman öğeleri kullanır, öznitelikler neredeyse hiç yoktur, bu nedenle XML'in okunması Ant'unkinden daha zordur!
Carl Smotricz

4
Son mermi için +1. Hiçbir şey günümü harika ve komik bir benzetme ile karşılaşmak gibi yapamaz, bu kadar doğru.
Adam

1
Belgeler zayıf değil, mükemmel.
HDave

96

Geçmişte kesinlikle maven hakkında şikayet ettim ve inledim . Ama şimdi onsuz olmazdım. Faydaların herhangi bir sorundan çok daha ağır bastığını hissediyorum. Başlıca:

  • Standartlaştırılmış proje yapısı.
    • Bir projeye katılan yeni bir geliştirici verildiğinde:
      • Bunun bir Maven projesi olduğunu söylediğinizde, geliştirici proje düzenini ve projeyi nasıl oluşturup paketleyeceğini bilir.
      • Bunun bir Ant projesi olduğunu söylediğinizde, geliştiricinin daha fazla açıklama yapmanızı beklemesi veya bir şeyleri anlamak için build.xml'ye gitmesi gerekecek.
    • Elbette, Ant ile şirket çapında bir standardı empoze etmek her zaman mümkündür, ancak çoğu zaman, meşhur çarkı yeniden icat edeceğinizi düşünüyorum.
  • Bağımlılık yönetimi.
    • Sadece harici kütüphanelerle değil, aynı zamanda dahili kütüphaneler / modüller ile de. Nexus veya benzeri bir Maven veri havuzu proxy sunucusu kullandığınızdan emin olun. Artifactory .
    • Bunun birazını Ivy ile yapmak mümkün . Aslında, ihtiyacınız olan tek şey bir bağımlılık yönetimi ise, muhtemelen Ivy'yi kullanmanız daha iyi olacaktır.
  • Özellikle bir proje içinde. Küçük alt projeleri ayırmayı oldukça faydalı buldum ve maven bunu iyi idare ediyor. Karınca ile çok daha zordur.
  • Standartlaştırılmış artefakt yönetimi (özellikle bağlantı noktası veya yapay )
  • Yayın eklentisi harika.
  • Eclipse & NetBeans entegrasyonu oldukça iyidir.
  • Hudson ile entegrasyon mükemmel. Findbugs gibi şeyler için özellikle trend grafikleri.
  • Bu küçük bir nokta, ama sürüm numarası gibi maven yerleştirmeler ayrıntıları Gerçek şu ki varsayılan olarak kavanoz ya da savaş (sadece dosya adı olarak) müthiş yararlıdır.

Benim için olumsuz taraflar başlıca:

  • Komut satırı pek yardımcı olmuyor. Bu başlangıçta beni çok rahatsız etti.
  • XML formatı çok ayrıntılı. Neden bu şekilde yapıldığını anlayabiliyorum, ama okumak hala acı veriyor.
    • Bununla birlikte, bir IDE'de kolay düzenleme için bir XSD'ye sahip olduğunu söyledi.
  • Başlangıçta kafanı etrafına dolaştırmak zor. Örneğin yaşam döngüsü gibi şeyler.

Maven'i tanımak için biraz zaman harcamaya değer olduğuna gerçekten inanıyorum.


2
XML formatını özellikle umursamıyorum (Eclipse sıkıcı parçaların çoğuna bakabilir) ve büyük projeler için talimatlar genellikle kötü ve karmaşıktır. Örneğin, GNU automake'ın umursamadığı bir şeyi yapmasını sağlamaya çalışana kadar kafanızı tuğla duvara gerçekten vurmamışsınızdır…
Donal Fellows

2
IntelliJ ayrıca mükemmel Maven desteğine sahiptir.
Steven Benitez

1
Ayrıntılarla birlikte mantıklı bir yanıt görün.
Tim O'Brien

80

İki büyük projeden edindiğim pratik deneyimim, maven 1'den maven 2'ye geçme konusunda 500 saatlik çaba haricinde, her proje için maven ile ilgili problemlerde 1000 - 1500 saat harcadığımızdır.

O zamandan beri maven'den kesinlikle nefret ettiğimi söylemeliyim. Bunu düşünürken hayal kırıklığına uğradım.

Eclipse entegrasyonu korkunç. (Örneğin, tutulmanın üretilen kodla senkronize edildiği ve sıklıkla tam bir yeniden inşa gerektiren kod üretme konusunda sonsuz sıkıntılarımız vardı. Suç hem maven hem de tutulmadır, ancak tutulma maven ve emacs'den daha yararlıdır, bu yüzden tutulma kalır ve maven gitmek zorunda.)

Çok fazla bağımlılığımız vardı ve keşfettiğimiz gibi, sözdizimi hataları aslında genel maven depolarına işleniyor, bu da değerli zamanınızın saatlerini mahvedebilir. Her hafta. Çözüm, bir proxy'ye veya yerel olarak yönetilen bir depoya sahip olmaktır ve bunun da düzeltilmesi oldukça zaman aldı.

Mavens proje yapısı Eclipse ile geliştirmeye pek uygun değil ve tutulmada inşa süresi artıyor.

Kod oluşturma ve senkronizasyon sorununun bir sonucu olarak, sık sık kazımadan yeniden inşa etmek zorunda kaldık, kod / derleme / test döngünüzü sonsuz bir derleme / websurf / uyku / kalıp / kod döngüsüne indirgeyerek sizi 90'lara geri gönderdik ve 40 dakikalık derleme süreleri.

Maven için tek bahane bağımlılık çözümüdür, ancak bunu her yapıda değil, arada bir yapmak istiyorum.

Özetlemek gerekirse, maven, KISS'ten olabildiğince uzak. Ayrıca savunucular, yaşlarının bir asal sayı olduğu doğum günlerinde fazladan kutlama yapan insanlar olma eğilimindedir. Bana oy vermekten çekinmeyin :-)


3
Aslında söylediklerinizden bazılarına katılıyorum, ancak sonunda doğru anladığımı düşünüyorum. İstediğinizi elde etmek için Ivy'ye bir göz atabilirsiniz, henüz denemediniz ama daha yapılandırılmış bir Ant ortamında bağımlılık yönetimi getiriyor gibi görünüyor.
Newtopian

5
Peki Maven'e iyi bir alternatif buldunuz mu?
Thilo

4
Eclipse entegrasyonu hala berbat. Güncel eklentilere sahip olmasına rağmen, belirsiz hata mesajlarıyla başarısız olan eklenti kontrollü maven görevleri vardır. Meslektaşlarım daha sonra bana bir komut kabuğuna düşüp aynı komutu çalıştırmamı söylediler ... sonra gizemli bir şekilde çalışıyor. Eclipse olgun bir ortam, maven eklentisi çok geride kalıyor.
Carl Smotricz

2
Maven ve Eclipse'in bir projenin ne olduğunu tanımlamasında temel bir fark var. Maven'de bir proje, kaynak kodunu düzenlemenin aşağı yukarı uygun bir yoludur. Eclipse başlangıçta, aynı anda bir veya birkaç alakasız proje üzerinde çalışabilmeniz için tasarlandı. Daha sonra (her zaman sağlam olmayan) gereksinimler, IBM'in projeleri, tutulmanın aslında oldukça kötü işlediği "modüller" olarak kötüye kullanmasına yol açar. Tanımları birleştirmek için, çoğu durumda, maven projelerinin muhtemelen tutulma kaynak klasörlerine eşlenmesi gerekir. Ancak, maven berbat olduğu için neden zahmet etsin.
KarlP

3
Hey! Bir dahaki sefere asal yaşım 29, bir sonraki mükemmel küp yaşım 64 ve son mükemmel penteract yaşım 32 olacak ... ama aktif olarak maven'i savunmuyorum.
cwallenpoole

46

Maven harika. Benim görüşüme göre, ününün nedeni dik öğrenme eğrisi ile ilgilidir. (sonunda aşmaya yakın olduğum)

Dokümantasyon biraz zor, çünkü anlam kazanmaya başlamadan önce anlaşılması gereken çok fazla metin ve yeni şeyler varmış gibi hissettiriyor. Maven'in daha çok övgü alması için gereken tek şeyin zaman olduğunu söylüyorum.


6
Bu biraz doğru olabilir, ancak Maven'in Eclipse ile entegrasyonunu kullanmanın gerçekten insanlar için öğrenme eğrisini kısaltmaya yardımcı olduğunu buldum. m2eclipse.codehaus.org
Taylor Leese

2
@Taylor, eklentiyle ilgili birçok sorun yaşadım, özellikle Eclipse'in başka bir sürümünü kullanıyorsanız veya cennet yasaklı RAD. Sanırım oraya
Dan

Bunu yalnızca Eclipse 3.3, 3.4 ve JBoss geliştirici stüdyosu ile kullandım ve bazı küçük sıkıntılar olduğunu kabul ettim (POM düzenleyicisinin iyi oynamaması gibi) ancak herhangi bir büyük sorun yaşamadım.
Taylor Leese

10
Beni rahatsız eden öğrenme eğrisi değil. Gerçekten anlamak o kadar da zor değil. Benim sorunum, büyük (ticari) projeler için, harcanan çabadan çok daha az değer elde etmenizdir. Tamam, projeleriniz inşa edilir. Harika, ama harcanan bir insan yılının maliyeti, dış etkenler nedeniyle sürekli kurulum hataları, 5 saniye yerine 10 dakikalık derlemeler ve çirkin bir tutulma çalışma alanı, buna değmez. Ayrıca, aynı maliyete, sürekli olarak bagajı manuel olarak yapan bir adamı aşağı yukarı kiralayabilirsiniz.
KarlP

8
@Karlp - henüz tam olarak anlamadınız ... 1.) "dış faktörlerden kaynaklanan arızalar" - tüm bağımlılıklarınızı içinde tuttuğunuz ve sürümlerini kontrol ettiğiniz bir proje havuzu oluşturmalısınız. 2.) "5 saniye yerine 10 dakikalık derlemeler" - belki de ilk maven kurulumu ve ilk derleme için - maven, ihtiyaç duyduğu tüm bağımlılıkları ve projenizi indirir - ancak kendi kodunuzu oluşturmaya çalışmak için yaptığınız normal derlemeler bunu yapmamalıdır indiriliyor - bkz. 1 - ayrıca, çevrimdışı mod. 3.) "çirkin tutulma çalışma alanı" - maven tüm büyük IDE'lerde (NB, IntelliJ) ve komut satırından çalışır.
Nate

24

Çünkü Maven, yetişkin erkekleri mutlak dehşet dolu kitleleri ağlatan bir cihazdır.


3
Kitlesel olarak üretmeli ve büyük bir kâr için tüm kötülere satmalıyız!
Joachim Sauer

7
Hayır! Maven kar için kullanılamaz. Sadece kötülük için kullanılabilir.
Apocalisp

18

Artıları:

  • Bağımlılık yönetimi. Zaten birkaç yıldır, iş arkadaşlarım ve ben bağımlılıkları manuel olarak indirip yönetmiyoruz. Bu büyük bir zaman tasarrufu sağlar.
  • IDE bağımsızlığı. Görünüşe göre, tüm büyük IDE'ler, Eclipse, IDEA ve NetBeans, geliştiricilerimizin belirli bir IDE'ye kilitlenmemesi için Maven projelerine nasıl iyi destek veriyorlar.
  • Komut satırı. Maven ile eşzamanlı IDE ve komut satırı yapılandırmalarını desteklemek basittir ve sürekli entegrasyon için iyidir.

Eksileri:

Rekabet:

  • Karınca: bağımlılık yönetimi yoktur. Dönem.
  • Ivy: Hala Maven'den daha az olgun (ikincisinin de tuhaflıkları olmadığı için değil). Neredeyse aynı özellik seti, bu nedenle hareket etmek için ikna edici bir neden yok. Denemek için birkaç girişimde bulundum; hepsi başarısız.

Sonuç olarak: Tüm projelerimiz birkaç yıldır Maven ile yapılmaktadır.


3
Karınca, Maven ile rekabet etmez. Ivy, Maven ile rekabet etmez (Maven Ant görevleriyle rekabet eder). Maven, bir inşa aracı + bağımlılık yönetiminden daha fazlasıdır. Dönem.
Pascal Thivent

18

En basit ve en karmaşık projelere sahip kişiler arasında kötü bir üne sahip olduğunu düşünüyorum.

Tek bir kod tabanından tek bir WAR oluşturuyorsanız, bu sizi proje yapınızı hareket ettirmeye ve üç kavanozdan ikisini POM dosyasına manuel olarak listelemeye zorlar.

Beş WAR dosyası, üç EJB ve diğer 17 araç, bağımlılık kavanozları ve son derleme sırasında mevcut kaynaklardaki MANIFEST.MF ve XML dosyalarının ince ayarını gerektiren yapılandırmalarla dokuz EAR dosya prototipinden oluşan bir setten bir EAR oluşturuyorsanız; o zaman Maven muhtemelen çok kısıtlayıcıdır. Böyle bir proje, karmaşık iç içe geçmiş profiller, özellikler dosyaları ve Maven yapı hedeflerinin ve Sınıflandırıcı atamasının kötüye kullanımından oluşan bir karmaşa haline gelir.

Yani, karmaşıklık eğrisinin en alt% 10'luk dilimindeyseniz, bu aşırıdır. Bu eğrinin en üst% 10'unda, deli gömleğindesin.

Maven'in büyümesi, orta% 80 için iyi çalıştığı için


16

Deneyimlerim, buradaki birçok gönderinin hayal kırıklığını yansıtıyor. Maven ile ilgili sorun, nihai otomatik büyülü iyilik arayışında yapı yönetiminin ayrıntılarını sarması ve gizlemesidir. Bu, kırılırsa sizi neredeyse çaresiz kılar.

Benim deneyimime göre, maven ile ilgili herhangi bir sorun, kök kanalına benzer bir deneyimde, iç içe geçmiş xml dosyalarının ağlarında çok saatlik bir su çulluğu avına dönüştü.

Maven'e büyük ölçüde bel bağlayan dükkanlarda da çalıştım, onu beğenenler ("bir düğmeye basın, hepsini yapın" yönünden hoşlananlar) bunu anlamadılar. Maven binalarının bir milyon otomatik hedefi vardı ve yaptıklarını okumak için saatler ayırmak istersem faydalı olacağına eminim. Tamamen anladığınız şekilde çalışan daha iyi 2 hedef.

uyarı: Maven ile en son 2 yıl önce çalıştı, şimdi daha iyi olabilir.


14

Glenn gibi, Maven'in kötü bir itibarı olduğunu düşünmüyorum, ama karışık bir repliği var. 6 aydır sadece oldukça büyük bir proje projesini Maven'e taşımaya çalışıyorum ve aracın sınırlarını açıkça gösteriyor.

Tecrübelerime göre, Maven şu konularda iyidir:

  • dış bağımlılık yönetimi
  • yapının merkezi yönetimi (pom mirası)
  • birçok şey için birçok eklenti
  • sürekli entegrasyon araçlarıyla çok iyi entegrasyon
  • çok iyi raporlama yetenekleri (FindBugs, PMD, Checkstyle, Javadoc, ...)

Ve bazı sorunları var:

  • ya hep ya hiç yaklaşımı (yavaş yavaş Maven'e geçmek zor)
  • karmaşık bağımlılıklar, modüller arası bağımlılıklar
  • döngüsel bağımlılıklar (biliyorum, kötü tasarım, ancak 5 yıllık geliştirmeyi düzeltemiyoruz ...)
  • tutarlılık (sürüm aralıkları her yerde aynı şekilde çalışmaz)
  • hatalar (yine sürüm aralıklarında)
  • yeniden üretilebilir yapılar (tüm eklentilerin sürüm numarasını düzeltmezseniz, aynı derlemeyi 6 ay içinde alacağınızdan emin olamazsınız)
  • belge eksikliği (belge temel bilgiler için oldukça iyidir, ancak büyük projelerin nasıl ele alınacağına dair çok fazla örnek yoktur)

Biraz bağlam vermek gerekirse, bu proje üzerinde çalışan yaklaşık 30 geliştirici var ve proje 5 yıldan fazla bir süredir var, yani: çok sayıda miras, çok sayıda işlem zaten mevcut, birçok özel tescilli araç zaten mevcut. Tescilli araçlarımızı sürdürmenin maliyeti çok yükseldiği için Maven'e geçmeye karar verdik.


12

Bu forumda yapılan şikayetlerden birkaçına karşı çıkmak istiyorum:

Maven ya hep ya hiçtir. Ya da en azından belgelerden anlayabildiğim kadarıyla. Karınca yerine maven'i kolayca kullanamazsınız ve yavaş yavaş daha gelişmiş özellikleri benimseyemezsiniz.

Bu doğru değil. Maven'in büyük kazancı, bağımlılıklarınızı rasyonel bir şekilde yönetmek için kullanmaktır ve eğer bunu maven'de yapmak ve diğer her şeyi karınca yapmak istiyorsanız, yapabilirsiniz. Bunu nasıl yapacağınız aşağıda açıklanmıştır:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Artık pom dosyasında tanımlanan tüm maven bağımlılıklarını içeren 'maven.classpath' adında bir sınıf yolu nesnesine sahipsiniz. Tek ihtiyacınız olan maven karınca görevleri kavanozunu karıncanızın kitaplık dizinine koymaktır.

Maven, oluşturma sürecinizi ağ bağlantınıza bağımlı hale getirir.

Varsayılan bağımlılık ve eklenti getirme süreci bir ağ bağlantısına bağlıdır, evet, ancak yalnızca ilk derleme için (veya kullanımdaki bağımlılıkları veya eklentileri değiştirirseniz). Bundan sonra tüm kavanozlar yerel olarak önbelleğe alınır. Ağ dışı bağlantıyı zorlamak istiyorsanız, maven'e çevrimdışı modu kullanmasını söyleyebilirsiniz.

Başlangıçtan itibaren size katı bir yapı uygular.

Bunun dosya biçimine mi yoksa "kurala karşı yapılandırma" sorununa mı atıfta bulunduğu net değil. İkincisi için, çok sayıda görünmez varsayılan var java kaynak dosyalarının ve kaynaklarının beklenen konumu veya kaynağın uyumluluğu gibi . Ancak bu katılık değil, sizin için mantıklı varsayılanlar koyuyor, böylece bunları açıkça tanımlamanıza gerek kalmaz. Tüm ayarlar oldukça kolay bir şekilde geçersiz kılınabilir (ancak yeni başlayanlar için belirli şeylerin nasıl değiştirileceğini belgelerde bulmak zor olabilir).

Dosya biçiminden bahsediyorsanız, bu bir sonraki bölümün yanıtında ele alınmaktadır ...

XML tabanlı olduğu için ANT kadar okunması zor.

Öncelikle, kötü bir repliğe sahip olmasının gerekçesi olarak bir şeyin bazı yönlerinin 'karıncadan daha iyi olmadığından' nasıl şikayet edebileceğinizi anlamıyorum. İkincisi, hala XML olmasına rağmen, XML'nin biçimi çok daha tanımlıdır. Dahası, bu şekilde tanımlandığı için, bir POM için mantıklı kalın bir istemci editörü yapmak çok daha kolaydır. Her yere atlayan sayfalarca uzun karınca inşa senaryoları gördüm. Herhangi bir ant build komut dosyası editörü bunu daha lezzetli hale getirmeyecek, sadece biraz farklı bir şekilde sunulan birbirine bağlı görevlerin uzun bir listesi.

Burada gördüğüm bazı geçersizliklere sahip olan veya sahip olduğum birkaç şikayet olduğunu söyledim, en büyük varlık

  • Belgeler zayıf / eksik
  • Tekrarlanabilir yapılar
  • Eclipse entegrasyonu kötü
  • Hatalar

Cevabımın iki katı olduğu. İlk olarak, Maven, Ant veya Make'den çok daha genç bir araçtır, bu nedenle bu uygulamaların olgunluk düzeyine ulaşmasının zaman alacağını beklemelisiniz. İkincisi, beğenmediyseniz düzeltin . Bu açık kaynak kodlu bir proje ve onu kullanmak ve sonra çözmede herkesin yardım edebileceği bir şeyden şikayet etmek bana oldukça aptalca görünüyor. Belgeleri beğenmediniz mi? Yeni başlayanlar için daha net, daha eksiksiz veya daha erişilebilir hale getirmek için katkıda bulunun.

Yeniden üretilebilir derlemeler sorunu iki konuya ayrılır: sürüm aralıkları ve otomatik maven eklenti güncellemeleri. Eklenti yükseltmeleri için, bir projeyi bir yıl sonra yeniden oluşturduğunuzda, aynı JDK'yı ve tam olarak aynı Ant sürümünü kullandığınızdan emin olmadığınız sürece, bu sadece farklı bir adla aynı problemdir. Sürüm aralıkları için, tüm doğrudan ve geçişli bağımlılıklar için kilitli sürümlere sahip geçici bir pom üretecek ve onu maven yayın yaşam döngüsünün bir parçası haline getirecek bir eklenti üzerinde çalışmanızı öneririm. Bu şekilde, sürüm oluşturma pomlarınız her zaman tüm bağımlılıkların tam açıklamaları olur.


11

Sahip olduğu itibarı hak ediyor. Herkes, Maven'in geliştiricilerinin her bir proje için uygun olduğunu düşündüğü katı yapıya ihtiyaç duymaz. Çok esnek değil. Ve birçok insan için 'Pro' olan bağımlılık yönetimi, IMHO'nun en büyük 'aleyhtarı'. Ağdan kavanozları indiren ve uyumsuzluklar yüzünden uykumu kaybeden maven konusunda kesinlikle rahat değilim (evet, çevrimdışı mod var, ama o zaman neden tüm bu yüzlerce xml dosyasına ve sağlama toplamına sahip olmalıyım). Hangi kitaplıkları kullandığıma ben karar veririm ve birçok projenin ağ bağlantısına bağlı derlemeler konusunda ciddi endişeleri vardır.

Daha da kötüsü, işler yürümediğinde kesinlikle kaybolursunuz. Belgeler berbat, topluluk habersiz.


4
Buna katılıyorum. Bağımlılık yönetiminin değerinin abartıldığını düşünüyorum. Elbette, her şey işe yaradığında düzgündür, ancak birkaç potansiyel arıza noktası ortaya çıkarır (potansiyel güvenlik açıklarından bahsetmeye gerek bile yok). Sorunları bir şekilde azaltmak için kendi depo sunucunuzu kurabilir ve beklenmedik güncellemeleri önlemek için sürüm numaralarını kilitleyebilirsiniz, ancak yine de bağımlılıkları sürüm kontrolüne eklemeyi tercih ederim çünkü bunlar çok sık değişmezler ve tekrarlanabilir bir yapıyı garanti eder. .
Dan Dyer

8

Bir yıl sonra bunu güncellemek istedim: Maven topluluğu hakkında artık bu fikrim yok. Soru bugün sorulsaydı bu cevabı yazmazdım. Mevcut fikrimi ayrı bir cevap olarak ekleyeceğim.


Bu çok öznel bir cevap, ancak soru fikirlerle ilgili, bu yüzden ...

Maven'i seviyorum ve onu daha çok tanıdıkça daha çok seviyorum. Bununla ilgili duygularımı etkileyen bir şey var: Maven topluluğu büyük ölçüde Sonatype (Maven şirketlerinin çoğunun çalıştığı yer) etrafında toplanıyor ve Sonatype, kurumsal ürünlerini topluluk üzerinde oldukça agresif bir şekilde zorluyor.

Bir örnek: "Maven Book" twitter akışı , depo yönetimine sözde bir girişle bağlantılıdır .

Maalesef bu "giriş" Nexus için yarı bilgi, yarı satış konuşması. Pop testi: var mı Nexus ve Nexus Pro dışında başka repo yöneticisi mı? Ayrıca, sözde açık kaynaklı Maven Kitabı ile ne ilgisi var? Oh, doğru, depo yönetimi ile ilgili bölüm ayrı bir kitap haline getirildi ... Nexus hakkında. Huh. Maven kitabına katkıda bulunursam, Nexus satışlarında bir artışa neden olursam tavsiye ücreti alır mıyım?

Bir Java geliştirme forumuna katıldığınızı ve Java'yı tartışan Sun çalışanlarının NetBeans ve "NetBeans Pro" hakkında konuşmak için mümkün olan her fırsatı değerlendireceklerinin açık olduğunu düşünün. Bir süre sonra toplum hissinin bir kısmını kaybeder. Ant'la hiç böyle bir deneyimim olmadı.

Tüm bunları söyledikten sonra, Maven'in yazılım geliştirme yapılandırması ve yapı yönetimi için çok ilginç ve kullanışlı bir sistem olduğunu düşünüyorum (buna Ant gibi bir araç demiyorum, Maven bundan daha geniş). Bağımlılık yönetimi bazen bir nimet ve lanet olabilir, ancak tazeleyicidir ve kesinlikle Maven'in sunduğu tek avantaj değildir. Muhtemelen Sonatip şiline biraz fazla tepki veriyorum, ancak bence bu Maven'i ilişkilendirerek incitiyor. Bu fikrin başka biri tarafından paylaşılıp paylaşılmadığını bilmiyorum.


2
Zac, Nexus Professional hakkında daha fazla şey öğrenmek isteyip istemediğini merak ettiğimi biliyorsun. :-)
Tim O'Brien

7

Bence Maven, projenize yapı yüklediği için kötü bir şöhrete sahip, oysa Ant gibi diğer araçlar yapıyı istediğiniz gibi tamamen tanımlamanıza izin veriyor. Belgelerin kötü olduğu konusunda da hemfikirim, ancak bence öncelikle Maven'in aldığı kötü rap, insanların Ant'a çok alışması.


2
Başlangıçta insanların Ant ile sahip oldukları kontrolü gözden kaçırabileceklerine katılıyorum, ancak bir proje Maven'in dayattığı sözleşmeleri kabul etmeye başladığında, bundan üretkenlikte gerçekten bir kazanç görecekler.
Taylor Leese

5
Doğru değil, Maven proje yapısını değiştirmenize izin veriyor, sadece yaygın olarak kullanılan bir yapı öneriyor.
adrian.tarau

3
Bunun doğru olduğunu sanmıyorum. Maven hakkındaki şikayetlerin çoğu, başarısız olma yolları, ne kadar yavaş olduğu veya dokümantasyonla ilgilidir. Yapısından şikayet eden birini hiç fark etmemiştim.
Dan Dyer

@Dan Dyer: Bunu ikinciyim. Yapı aslında Maven'in yaptığı birkaç iyi şeyden biridir. Maven'i bu kadar korkunç yapan her şeydir.
Carl Smotricz

6

Çok fazla sihir.


3
Daha spesifik olun - bununla ilgili belgelenmemiş kadar büyülü olan ne?
whaley

4
Bir şeyin neden beklendiği gibi çalışmadığını anlamak için 2 saat boyunca internette arama yapmanız gerektiği anda büyülü. Belirli bir örnek istiyorsanız: eklentim neden çalıştırılmadı? 2 saatin var.
Damien B

Aslında, 2 saat boyunca internette arama yapmayı gerektirmeyen bir şey yaptığımda, iş için yanlış aracı kullandığımdan veya gereksinimleri ciddi şekilde yanlış anladığım / hafife aldığımdan şüphelenmeye başlıyorum.
Doug Moscrop

6

Çünkü tatminsiz insanlar şikayet ederken, tatmin olanlar tatmin olduklarını söylemezler. Demek istediğim, memnun olmayanlardan çok daha fazla memnun maven kullanıcısı var, ancak daha sonra daha fazla gürültü çıkar. Bu, gerçek hayatta da yaygın bir modeldir (ISS, telefon operatörü, nakliyeler vb.).


5

Benim için en önemli tek sorun, Maven'in doğru şekilde yapılandırılmadığında aşağıdaki nedenlerden dolayı tekrarlanabilir yapılar üretememesidir:

  • güvenilmez uzak depolar;
  • SNAPSHOT sürümleri olan veya sürümü olmayan eklentilere ve kitaplıklara bağımlılıklar.

Bunu, ayrıntılı ve yorucu IMO olmasına rağmen, tüm kavanozlar yerel olarak kontrol edildiğinden işe yarayan bir karınca yapısıyla karşılaştırın.

İşin iyi yanı, sorunların çözülebilir olmasıdır:

  • son derece basit hale gelen kendi maven deponuzu kullanın, Archiva'yı iyi sonuçlarla kullanıyorum;
  • bağımlılıklarınızı her zaman doğru şekilde versiyonlayın. Maven, 2.0.8 veya 2.0.9'dan başlayarak süper POM'daki eklenti sürümlerini kilitlemeye başladı ve tüm bağımlılıklarınız yayımlanmış sürümlerde olmalıdır.

Alternatif bir depo uygulamasına bağlanmak için +1.
Donal Fellows

5

harika fikir - kötü uygulama.

Geçenlerde Ant'tan Maven'e bir proje taşıdım. Sonunda iyi çalıştı, ancak aynı pomda iki farklı maven-assembly-plugin ve maven-jar-plugin versiyonunu kullanmak zorunda kaldım (iki profil var) çünkü bir versiyonda çalışan bir diğerinde bozulmuştu.

Yani oldukça baş ağrısıydı. Belgeler her zaman harika değildir, ancak Google cevaplarının nispeten kolay olduğunu kabul etmeliyim.

her zaman kullandığınız eklenti sürümlerini belirttiğinizden emin olun. Yeni sürümün geriye dönük olarak uyumlu olmasını beklemeyin.

Tartışmanın, maven'in hala evrim geçirmesinden ve sürecin bazen acı verici olmasından kaynaklandığını düşünüyorum.

Saygılarımızla

v.


Fikrin infazdan daha iyi olduğuna katılıyorum. Savunmak için seçtikleri küçük bir görev değildi, ancak işlerin daha basit bir şekilde yapılamayacağını merak ediyorum.
Eelco

5

Maven'i severim. 1.0'dan beri kullanıyorum. Dengeli olarak bana önemli miktarda zaman kazandıran ve geliştirme altyapımı iyileştiren güçlü bir araçtır. Ama bazı insanların yaşadığı hayal kırıklığını anlayabiliyorum. 3 tür hayal kırıklığı görüyorum:

  1. nedenlerin gerçek endişeler olduğu durumlarda (örneğin ayrıntılı POM'lar, dokümantasyon eksikliği),
  2. bazıları yanlış bilgidir (ör. "kurmak için internet bağlantınızın olması gerekir" - doğru değil - değil, bu önlenebilir),
  3. bir kısmı maven'de havalandırılır ama gerçekten başka biri suçludur ("elçiyi vurmayın").

İlk durum için, gerçek sorunlar - pekala, tabii ki sorunlar var, POM'lar ayrıntılı, dokümantasyon daha iyi olabilir. Ancak buna rağmen kısa sürede maven ile iyi sonuçlar almak mümkündür. Ant ile inşa edilmiş bir projeyi her aldığımda utanıyorum ve bunu IDE'me aktarmaya çalışıyorum. Dizin yapısını kurmak uzun zaman alabilir. maven ile, bu sadece POM dosyasını IDE'de açma durumudur.

İkinci durumda, Maven karmaşıktır ve yanlış anlaşılmalar olağandır. Maven 3 bu karmaşıklığı (hatta algılanan karmaşıklığı) ele almanın bir yolunu bulabilirse bu iyi olur. maven hatırı sayılır bir yatırım alıyor, ancak benim deneyimlerime göre, yatırım kendini çabucak karşılıyor.

Son olarak, maven'in geçişli bağımlılıkları hakkındaki yakınmanın muhtemelen en iyi bilinen örnek olduğunu düşünüyorum.

Geçişli bağımlılıklar, yeniden kullanımı kullanan gerçek yazılımın doğasıdır. Windows DLL'leri, Debian paketleri, java paketleri, OSGi paketleri, hatta C ++ başlık dosyası bile tümünün bağımlılıkları vardır ve bağımlılık sorunu yaşarlar. İki bağımlılığınız varsa ve her biri aynı şeyin farklı bir sürümünü kullanıyorsa, o zaman bunu bir şekilde çözmeye çalışmalısınız. Maven bağımlılık sorununu çözmeye çalışmaz, daha çok ön plana çıkarır ve çatışmaları bildirerek ve bir proje hiyerarşisi için tutarlı bağımlılıklar sağlayarak sorunu yönetmeye yardımcı olacak araçlar sağlar ve aslında üzerinde mutlak kontrol sağlar. bir projenin bağımlılıkları.

Her projeye bağımlılıkları manuel olarak dahil etme yaklaşımı (bir poster, tüm bağımlılıkları kaynak kontrolüne kontrol ettiğini söylüyor), bir kitaplık bağımlılıkları için güncellemeleri kontrol etmeden güncellendiğinde gözden kaçan güncellemeler gibi yanlış bağımlılığı kullanma riskini taşıyor. Her boyutta bir proje için, bağımlılıkları manuel olarak yönetmek kesinlikle hatalara yol açacaktır. Maven ile kullandığınız kitaplık sürümünü güncelleyebilirsiniz ve doğru bağımlılıklar dahil edilir. Değişiklik yönetimi için, eski bağımlılıklar setini (bir bütün olarak projeniz için) yeni setle karşılaştırabilirsiniz ve herhangi bir değişiklik dikkatlice incelenebilir, test edilebilir vb.

Maven, bağımlılık sorununun nedeni değildir, ancak daha görünür hale getirir. Bağımlılık sorunlarının üstesinden gelirken, kavanozların basitçe mevcut olduğu sürüm kontrolünde manuel olarak yönetilen kavanozlarda olduğu gibi, maven herhangi bir bağımlılık "ince ayarını" örtük değil (bağımlılığı geçersiz kılan POM'nuzda bir değişiklik) açıkça yapar. doğru bağımlılık olup olmadıkları havayı destekleyin.


5

Maven'ın kötü bir temsilcisi olduğuna inanıyorum çünkü çoğu kötüleyici Maven + Hudson + Sonar kombinasyonunu gözlemlemedi . Olsaydı, "nasıl başlayabilirim" diye sorarlardı?


Sonardan bahsettiğiniz için +1.
Donal Fellows

1
Onu görmüştüm. Maven'i kullanmak için hala bir neden yok. Hudson ve Sonar'ın maven'a ihtiyacı yok.
rk2010

5

Evcil hayvanımdan bazıları Maven ile sinirleniyor:

  • XML tanımı son derece beceriksiz ve ayrıntılıdır. Öznitelikleri hiç duymamışlar mı?

  • Varsayılan yapılandırmasında, her işlemde her zaman 'ağı tarar. Bunun herhangi bir şey için yararlı olup olmadığına bakılmaksızın, "temiz" için İnternet erişimine ihtiyaç duymak son derece aptalca görünüyor.

  • Yine varsayılan olarak, tam sürüm numaralarını belirtme konusunda dikkatli olmazsam, bu en yeni sürümlerin bağımlılık hataları getirip getirmediğine bakılmaksızın en son güncellemeleri ağdan çekecektir. Başka bir deyişle, diğer insanların bağımlılık yönetiminin insafına kalıyorsunuz.

  • Tüm bu ağ erişiminin çözümü, -oseçeneği ekleyerek kapatmaktır . Ancak gerçekten bağımlılık güncellemesi yapmak istiyorsanız, onu kapatmayı unutmamalısınız!

  • Diğer bir çözüm, bağımlılıklar için kendi "kaynak kontrol" sunucunuzu kurmaktır. Sürpriz: Çoğu projede zaten kaynak denetimi vardır, yalnızca bu ek kurulum olmadan çalışır!

  • Maven derlemeleri inanılmaz derecede yavaş. Ağ güncellemeleriyle uğraşmak bunu hafifletir, ancak Maven derlemeleri hala yavaştır. Ve korkunç derecede ayrıntılı.

  • Maven eklentisi (M2Eclipse) Eclipse ile en zayıf şekilde bütünleşir. Eclipse, sürüm kontrol yazılımı ve Ant ile oldukça sorunsuz bir şekilde entegre olur. Karşılaştırıldığında Maven entegrasyonu çok hantal ve çirkin. Yavaştan bahsetmiş miydim?

  • Maven, adamcağız olmaya devam ediyor. Hata mesajları işe yaramaz. Çok fazla geliştirici bundan muzdarip.


2
Bir SNAPSHOT bağımlılığı kullanmadığım veya bir şey gerektiren yeni bir özellik eklemediğim sürece Maven'in bağımlılıktan en son halini almamıştım. 1.2.3 sürümünü sorarsam ve yerel depomda 1.2.3 varsa, 1.2.3'ü tekrar alamıyorum.
Mike Cornell

1
Doğrudan bağımlılıklarınızı kontrol edersiniz, evet. Bağımlılıklarınızın bağımlılıklarını kim kontrol ediyor?
Carl Smotricz

Önümüzdeki dönemde ele alınması gereken niteliklerle ilgili ilk noktanız için (artık uzun bir süredir itiraf edeceğim) Maven 3.
mezmo

@mezmo: Bu çok hoş karşılanır. Bilgi için teşekkürler!
Carl Smotricz

4

İyi soru. İş yerinde büyük bir projeye yeni başladım ve önceki projelerin bir kısmı kod tabanımıza modülerlik getirmekti.

Maven hakkında kötü şeyler duydum. Aslında, tüm duyduğum bu. Şu anda yaşadığımız bağımlılık kabusunu çözmek için onu tanıtmaya baktım. Maven ile gördüğüm sorun, yapısının oldukça katı olması, yani sizin için çalışması için proje düzenine uymanız gerekiyor.

Çoğu insanın ne söyleyeceğini biliyorum - yapıya uymak zorunda değilsin. Aslında bu doğru, ancak başlangıçtaki öğrenme eğrisini geçene kadar bunu bilemezsiniz, bu noktada gitmek ve hepsini atmak için çok fazla zaman harcarsınız.

Ant bugünlerde çok kullanılıyor ve ben onu seviyorum. Bunu hesaba katarak Apache Ivy adında az bilinen bir bağımlılık yöneticisine rastladım . Ivy, Ant ile çok iyi bütünleşiyor ve temel JAR alma kurulumunu ve çalışmasını sağlamak hızlı ve kolaydır. Ivy'nin bir başka yararı da çok güçlü ve oldukça şeffaf olmasıdır; scp veya ssh gibi mekanizmaları kullanarak derlemeleri kolayca aktarabilirsiniz; Dosya sistemleri veya uzak depolar üzerinden 'zincir' bağımlılık alımı (Maven repo uyumluluğu, popüler özelliklerinden biridir).

Her şey söylendi, sonunda kullanmayı çok sinir bozucu buldum - belgeler çok fazla, ancak hata ayıklarken veya neyin yanlış gittiğini çözmeye çalışırken hayal kırıklığına neden olabilecek kötü bir İngilizce ile yazılmış.

Bu proje sırasında bir noktada Apache Ivy'yi tekrar ziyaret edeceğim ve düzgün çalışmasını umuyorum. Yaptığı şeylerden biri, ekip olarak hangi kitaplıklara bağlı olduğumuzu belirlememize ve belgelenmiş bir liste almamıza izin vermekti.

Sonuçta ben her ne kadar aşağı gelir düşünüyorum Eğer bireysel / takım ve ne olarak çalışmak size sizin bağımlılık sorunları çözmek gerekir.

Ivy ile ilgili aşağıdaki kaynakları yararlı bulabilirsiniz:


1
Ivy, Maven ile rekabet etmez (belki Maven Ant Tasks ile ama Maven ile değil).
Pascal Thivent

1
Ivy, Maven Ant Tasks ile rekabet etmez, Maven bağımlılık yönetimi ile rekabet eder.
Damien B

@atc Bu haklıydı !! : "Çoğu insanın ne söyleyeceğini biliyorum - yapıya uymak zorunda değilsin. Aslında bu doğru ama bunu ilk öğrenme eğrisini geçene kadar bilemezsin, bu noktada çok fazla zaman harcıyorsun gidip hepsini atmak için. "
rk2010

4

Maven'i seviyorum - üretkenliği artırıyor ve artık Ant'ı kullanmadığım için çok mutluyum (phew!)

Ama bir şeyleri değiştirebilseydim şu olurdu:

  1. Yap pom.xmldosyası az ayrıntılı
  2. Depodan değil .jars'ı dahil etmeyi kolaylaştırın.

1
Bence Maven kullanıcıları, IDE'lerin eksik veya 3. taraf kavanozları yerel depolara içe aktarmasına izin vererek daha iyi hizmet verir. Bir "jar tıklamasını içe aktarmayı seç" iletişim kutusuna sahip olmak ne kadar zor olurdu?
sal

@sal Tahminimce Maven taşınabilirliği bozan bir uygulamayı tanıtmak istemiyor.
Pascal Thivent

1
Rastgele yerlerden kavanoz eklemenin zor olduğu gerçeğini bir güç olarak görüyorum. Bir ekip ortamındaysanız ve garip bir kavanoz kullanmanız gerekiyorsa, bu kavanozu ekibinizin maven deposuna yerleştirmelisiniz. Bu şekilde, ekibin geri kalanı ve CI sunucularınız aynı yapıyı gerçekleştirecek. Herkesin aynı yapıyı çalıştırması, maven felsefesinin temelidir.
tunaranch

Kavanoz şey için +1. Kendi önceden hazırlanmış kavanozlarınızı bir yapıda (herhangi bir nedenle) getirmek gereksiz bir acıdır.
Thorbjørn Ravn Andersen

@tunaranch şahsen, ya öğelerin Maven Central'da olmasını ya da sürüm kontrolünden kontrol edilen şeyde (kavanozlar ve hepsi) olmasını seviyorum . Temel olarak git depomu bir USB sürücüsüne getirebilmek, kontrol etmek, "mvn clean install" komutunu çalıştırmak ve öğle yemeğine gidip çalışır durumda olmak istiyorum.
Thorbjørn Ravn Andersen

4

İnsanların Maven'i sevmemesinin pek çok nedeni var, ancak kabul edin, bunlar çok öznel . Bugün bazı iyi (ve ücretsiz) kitaplar, daha iyi dokümantasyon, daha büyük eklenti seti ve birçok başarılı başarılı proje derlemesiyle Maven, bir veya iki yıl önceki Maven ile aynı değil.

Maven'i basit projelerde kullanmak çok kolaydır, daha büyük / karmaşık projelerde daha fazla bilgiye ve Maven felsefesinin daha derinlemesine anlaşılmasına ihtiyaç vardır - belki de şirket düzeyinde ağ yöneticisi gibi Maven gurusu için bir pozisyon. Maven nefret beyanlarının ana kaynağı genellikle cehalettir .

Maven için bir diğer kıkırdama, örneğin Ant'ta olduğu gibi esnekliğin olmamasıdır. Ancak Maven'ın bir dizi geleneğe sahip olduğunu hatırlayın - bunlara bağlı kalmak başlangıçta zor gibi görünüyor, ancak sonunda genellikle sorunlardan kurtulun.

Maven'in mevcut başarısı değerini kanıtlıyor. Elbette kimse mükemmel değildir ve Maven'ın bazı dezavantajları ve tuhaflıkları vardır ama bence Maven rakiplerini yavaşça savuruyor.


@Pascal. Maven ile ilgili sorun olması durumunda bir yığın taşması söz konusudur ve siz buradasınız :)
cetnar

3

Karışık bir repliği olduğu kadar kötü bir repliği olduğunu söyleyemem. Projeniz, Maven tarafından savunulan "konfigürasyon yerine kongre" paradigmasını takip ediyorsa, bundan çok yararlanabilirsiniz. Projeniz Maven'in dünya görüşüne tam olarak uymazsa, o zaman bir yük haline gelebilir.

Bu amaçla, proje üzerinde kontrole sahipseniz, Maven gidecek yol olabilir. Ancak yapmazsanız ve düzen Maven hayranı olmayan biri tarafından belirlenirse, değerinden daha fazla sorun olabilir. En mutlu Maven projeleri muhtemelen Maven projeleri olarak başlayan projelerdir.


"Karışık bir temsilciye sahip olduğu için kötü bir temsilcisi olduğunu söyleyemem" - bunun muhtemelen daha doğru olduğunu söyleyebilirim, yalnızca olumsuz görüşler daha fazla öne çıkma eğilimindedir.
Dan

Bir projeyi maven'e taşımanın, proje boyutuna göre deneysel olarak zorluğun arttığını kabul ediyorum (daha büyük projenin içe aktarılması = daha zor içe aktarılması). Bir projeye başlamak için maven kullanmak, maven'i kullanmak için en iyi yaklaşımdır. Aksi takdirde çabaya değmeyebilir.
Luigimax

3

Bana göre, şirket içi projeler için maven vs ant kullanmanın dezavantajları olduğu kadar artıları da var. Ancak açık kaynaklı projeler için, Maven'in birçok projenin oluşturulmasını çok daha kolay hale getirmede büyük etkisi olduğunu düşünüyorum. Çok uzun zaman önce, ortalama OSS Java (karınca tabanlı) projesini derlemek, tonlarca değişken ayarlamak, bağımlı projeleri indirmek vb. İçin saatler sürmedi.

Maven ile Ant ile yapabileceğiniz her şeyi yapabilirsiniz, ancak Ant'ın herhangi bir standardı teşvik etmediği durumlarda, Maven size kuvvetle onun yapısını takip etmenizi önerir, yoksa daha fazla iş olur. Doğru, bazı şeyler Maven ile kurmak için bir acıdır ve Ant ile yapılması kolay olabilir, ancak sonuç neredeyse her zaman sadece bir projeyi kontrol edip gitmek isteyen insanların bakış açısından inşa etmesi daha kolay olan bir şeydir.


3

Bir geliştirme projesine işiniz veya işinizle bahse girecekseniz, temellerin, yani inşa sisteminin kontrolünü elinizde tutmak istersiniz. Maven ile kontrol sizde değil. Açıklayıcı ve opaktır. Maven-framework geliştiricilerinin şeffaf veya sezgisel bir sistemin nasıl kurulacağı hakkında hiçbir fikri yoktur ve bu, günlük çıktısı ve belgelerden anlaşılır.

Bağımlılık yönetimi, projenin başlangıcında bir süre sizinle aynı olabileceği için çok caziptir, ancak uyarılır, temelde bozulur ve sonunda size çok fazla baş ağrısına neden olur. İki bağımlılığın uyumsuz geçici bağımlılıkları olduğunda, tüm ekibiniz için yapıyı bozacak ve günlerce geliştirmeyi engelleyecek bir fare karmaşıklığı yuvası tarafından engelleneceksiniz. Maven ile derleme süreci, yerel depolarının tutarsız durumları nedeniyle ekibinizdeki farklı geliştiriciler için de oldukça tutarsızdır. Bir geliştiricinin ortamını ne zaman oluşturduğuna veya başka hangi projelerde çalıştığına bağlı olarak farklı sonuçlar elde ederler. Tüm yerel deponuzu sildiğinizi ve bir geliştirme dalı için ilk kurulumdan çok daha sık Maven kavanozlarını yeniden indirdiğinizi göreceksiniz. OSGI'nin bu temel sorunu çözmeye çalışan bir girişim olduğuna inanıyorum. Belki de bir şeyin bu kadar karmaşık olması gerekiyorsa, temel önermenin yanlış olduğunu söyleyebilirim.

5 yıldan fazla bir süredir maven kullanıcısı / kurbanıyım ve kaynak deponuza bağımlılıklarınızı kontrol etmenin ve güzel ve basit karınca görevleri yazmanın size çok daha fazla zaman kazandıracağını söylemeliyim. Ant ile, inşa sisteminizin tam olarak ne yaptığını bilirsiniz.

Maven sorunları nedeniyle birkaç farklı şirkette haftalarca birçok kayıp adam yaşadım.

Yakın zamanda eski bir GWT / Maven / Eclipse projesini hayata döndürmeye çalıştım ve tüm boş zamanlarımın 2 haftasından sonra, hala tutarlı bir şekilde inşa edemiyorum. Kayıplarımı azaltmanın ve karınca / tutulmayı kullanarak geliştirmenin zamanı geldi diye düşünüyorum ...


3

Kısa cevap: Bir Maven inşa sistemini sürdürmeyi çok zor buldum ve olabildiğince çabuk Gradle'a geçmek istiyorum.

Maven ile dört yılı aşkın süredir çalışıyorum. Kendimi derleme sistemleri konusunda bir uzman olarak adlandırırım çünkü bulunduğum son (en az) beş şirkette, derleme / dağıtma altyapısı üzerinde büyük yenilemeler yaptım.

Öğrendiğim derslerden bazıları:

  • Çoğu geliştirici, geliştirme sistemleri hakkında çok fazla zaman harcamama eğilimindedir; Sonuç olarak, yapı bir spagetti karışıklığına dönüşüyor, ancak bu dağınıklık temizlendiğinde ve rasyonelleştirildiğinde bunu takdir ediyorlar.
  • Karmaşıklıkla uğraşırken, Maven gibi katı kısıtlamalar getirerek karmaşık şeyleri basitleştirmeye çalışan bir sistem yerine (Ant gibi) karmaşıklığı ortaya çıkaran şeffaf bir sisteme sahip olmayı tercih ederim. Linux ile Windows'u düşünün.
  • Maven, işlevsellikte bizans geçici çözümlerini gerektiren birçok deliğe sahiptir. Bu, anlaşılmaz ve sürdürülemez POM dosyalarına yol açar.
  • Ant süper esnek ve anlaşılır bir sistemdir, ancak Ant dosyaları da oldukça büyük olabilir çünkü çok düşük seviyelidir.
  • Herhangi bir önemli proje için, geliştiricilerin aracın sağladığının ötesinde kendi oluşturma / dağıtım yapılarını oluşturmaları gerekir; Yapının projeye uygunluğunun, bakımının ne kadar kolay olduğu ile yakından ilgisi vardır. En iyi araçlar, bir yapı oluşturmada size destek olur ve sizinle savaşmaz.

Gradle'a biraz baktım ve her iki dünyanın da en iyisi olma potansiyeline sahip gibi görünüyor, bu da bildirimsel ve prosedürel yapı açıklamasının bir karışımına izin veriyor.


3

Projenizi yazmak için kullandığınız dilden daha karmaşık. Doğru yapılandırmak, gerçek programlamadan daha zordur.


3

Burada bahsedilen olumsuzlukların çoğunu / tümünü ve takım arkadaşlarından gelen benzer itirazları aşmak için mücadele ettim ve hepsine katılıyorum. Ama ben bunu geride bıraktım ve bunu, yalnızca mavinin (veya belki de kademeli olarak) gerçekten gerçekleştirdiği tek hedefe sıkı sıkıya bağlı kalarak yapmaya devam edeceğim.

Eşler (açık kaynak geliştiriciler ) için optimize ediyorsanız , ant / make / ne yapacaksa onu yapın. Eş olmayanlara ( kullanıcılar ) işlevsellik sunuyorsanız , yalnızca maven / gradle / etc yeterli olacaktır.

Yalnızca maven, özümsememiş biri tarafından herhangi bir IDE tarafından yüklenebilen iyi belgelenmiş standart bir proje düzenine sahip küçük bir kaynak kodu + pom paketi (şifreli adlara sahip gömülü kitap / ikili bağımlılık kavanozları ve bağımlılık bilgileri yoktur) yayınlamanıza izin verir. geliştiricilerin kendine özgü düzen kuralları. Ve eksik bağımlılıkları alırken her şeyi oluşturan tek düğmeli bir yükleme prosedürü (mvn kurulumu) vardır.

Sonuç, kullanıcıların koda girmek için takip edebilecekleri kolay bir rampadır ve pomlar onları ilgili belgelere yönlendirebilir.

Bunun (olmazsa olmaz) dışında ben de herkes kadar maven'i sevmiyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.