Mengapa Maven memiliki reputasi yang buruk? [Tutup]

Ada banyak pembicaraan di internet tentang bagaimana Maven itu buruk. Saya telah menggunakan beberapa fitur Maven selama beberapa tahun sekarang dan manfaat terpenting dalam pandangan saya adalah manajemen ketergantungan.

Dokumentasi Maven kurang dari cukup, tetapi umumnya ketika saya perlu menyelesaikan sesuatu, saya mengetahuinya sekali dan kemudian berhasil (misalnya ketika saya menerapkan penandatanganan toples). Saya tidak berpikir bahwa Maven hebat, tetapi itu memecahkan beberapa masalah yang tanpanya akan menjadi rasa sakit yang tulus.

Jadi, mengapa Maven memiliki reputasi yang buruk dan masalah apa dengan Maven yang dapat saya harapkan di masa depan? Mungkin ada alternatif yang jauh lebih baik yang saya tidak tahu? (Misalnya, saya tidak pernah melihat Ivy secara detail.)

CATATAN: Ini bukan upaya untuk menimbulkan argumen. Ini merupakan upaya untuk menghapus FUD.

Saya melihat ke maven sekitar enam bulan lalu. Kami memulai proyek baru, dan tidak memiliki warisan untuk didukung. Yang mengatakan:

• Maven adalah semua-atau-tidak sama sekali. Atau setidaknya sejauh yang saya tahu dari dokumentasinya. Anda tidak dapat dengan mudah menggunakan maven sebagai pengganti semut, dan secara bertahap mengadopsi fitur yang lebih canggih.
• Menurut dokumentasi, Maven adalah kebahagiaan transendental yang membuat semua impian terliar Anda menjadi kenyataan. Anda hanya perlu bermeditasi pada manual selama 10 tahun sebelum Anda menjadi tercerahkan.
• Maven membuat proses build Anda bergantung pada koneksi jaringan Anda.
• Maven memiliki pesan kesalahan yang tidak berguna. Bandingkan ant "Target x tidak ada dalam proyek y" dengan "Tugas tidak valid 'run' mvn: Anda harus menentukan fase siklus hidup yang valid, atau tujuan dalam format plugin: goal atau pluginGroupId: pluginArtifactId: pluginVersion: goal" Bermanfaat, itu menyarankan saya menjalankan mvn dengan -e untuk informasi lebih lanjut, yang berarti itu akan mencetak pesan yang sama, kemudian jejak tumpukan untuk BuildFailureException.

Sebagian besar ketidaksukaan saya pada maven dapat dijelaskan dengan kutipan berikut dari Better Builds with Maven:

Ketika seseorang ingin tahu apa itu Maven, mereka biasanya akan bertanya "Apa sebenarnya Maven itu?", Dan mereka mengharapkan jawaban singkat yang terdengar langsung. "Yah, itu adalah alat membangun atau kerangka kerja skrip" Maven lebih dari tiga kata yang membosankan dan tidak menginspirasi. Ini adalah kombinasi dari ide, standar, dan perangkat lunak, dan tidak mungkin untuk menyaring definisi Maven hanya dengan mencerna gigitan suara. Ide revolusioner seringkali sulit untuk disampaikan dengan kata-kata.

Saran saya: jika Anda tidak dapat menyampaikan ide dengan kata-kata, Anda tidak boleh mencoba menulis buku tentang subjek tersebut, karena saya tidak akan menyerap ide secara telepati.

• Itu memaksakan struktur yang kaku pada Anda sejak awal.
• Ini berbasis XML sehingga sulit dibaca seperti ANT sebelumnya.
• Pelaporan kesalahannya tidak jelas dan membuat Anda terdampar saat terjadi kesalahan.
• Dokumentasinya buruk.
• Itu membuat hal-hal yang sulit menjadi mudah, dan hal-hal yang sederhana menjadi sulit.
• Membutuhkan terlalu banyak waktu untuk mempertahankan lingkungan build Maven, yang mengalahkan poin memiliki sistem build yang serba bernyanyi.
• Butuh waktu lama untuk mengetahui bahwa Anda telah menemukan bug di maven dan tidak mengkonfigurasi sesuatu yang salah. Dan serangga itu memang ada, dan di tempat yang mengejutkan.
• Itu menjanjikan banyak tetapi mengkhianati Anda seperti kekasih yang cantik dan menggoda tetapi secara emosional dingin dan manipulatif.

Saya pasti pernah mengomel & mengeluh tentang maven di masa lalu. Tapi sekarang, saya tidak akan tanpanya. Saya merasa bahwa manfaatnya jauh lebih besar daripada masalah apa pun. Terutama:

• Struktur proyek standar.
  • Diberikan pengembang baru bergabung dengan proyek:
    • Ketika Anda mengatakan ini adalah proyek Maven, maka pengembang mengetahui tata letak proyek dan cara membangun serta mengemas proyek tersebut
    • Ketika Anda mengatakan itu adalah proyek Ant, maka pengembang harus menunggu Anda untuk menjelaskan lebih lanjut atau harus melalui build.xml untuk mencari tahu.
  • Tentu saja, selalu mungkin untuk memaksakan standar seluruh perusahaan dengan Ant tetapi saya pikir lebih sering daripada tidak, Anda akan menemukan kembali roda pepatah.
• Manajemen ketergantungan.
  • Tidak hanya dengan perpustakaan eksternal tetapi juga dengan perpustakaan / modul internal. Pastikan untuk menggunakan server proxy repositori Maven seperti Nexus atau Artifactory .
  • Hal ini mungkin dilakukan dengan Ivy . Faktanya, jika yang Anda butuhkan hanyalah manajemen ketergantungan, Anda mungkin lebih baik menggunakan Ivy.
• Terutama dalam sebuah proyek. Saya merasa cukup berguna untuk memecah subproyek kecil, dan maven menangani ini dengan baik. Jauh lebih sulit dengan semut.
• Manajemen artefak standar (terutama dalam hubungannya dengan nexus atau artifactory )
• Plugin rilis luar biasa.
• Integrasi Eclipse & NetBeans cukup bagus.
• Integrasi dengan hudson luar biasa. Terutama grafik tren untuk hal-hal seperti findbugs.
• Ini poin kecil, tetapi fakta bahwa maven menyematkan detail seperti nomor versi di dalam toples atau war (tidak hanya di nama file) secara default sangat membantu.

Kerugian bagi saya terutama:

• Baris perintah cukup tidak membantu. Ini membuat saya kesal untuk memulai.
• Format XML sangat bertele-tele. Saya dapat melihat mengapa hal itu dilakukan seperti itu, tetapi masih sulit untuk dibaca.
  • Karena itu, ia memiliki XSD untuk memudahkan pengeditan dalam IDE.
• Sulit untuk memusatkan perhatian pada awalnya. Hal-hal seperti siklus hidup, misalnya.
  • Panduan definitif untuk maven adalah pengantar yang bagus.

Saya benar-benar percaya bahwa ada baiknya menghabiskan sedikit waktu untuk mengenal maven.

Pengalaman praktis saya dari dua proyek besar adalah bahwa kami telah menghabiskan 1000 - 1500 jam untuk setiap proyek pada masalah terkait maven, tidak termasuk upaya 500 jam untuk berpindah dari maven 1 ke maven 2.

Sejak itu, saya harus mengatakan bahwa saya sangat membenci Maven. Saya menjadi frustrasi ketika memikirkannya.

Integrasi Eclipse sangat buruk. (Kami memiliki masalah yang tak ada habisnya dengan pembuatan kode misalnya, di mana gerhana tidak sinkron dengan kode yang dihasilkan, dan memerlukan pembangunan kembali yang cukup, cukup sering. Kesalahannya adalah maven dan gerhana, tetapi gerhana lebih berguna daripada maven dan mengatakan emacs, jadi gerhana tetap dan maven harus pergi.)

Kami memiliki banyak dependensi, dan seperti yang kami temukan, kesalahan sintaks sebenarnya sering terjadi pada repositori maven publik, yang dapat merusak waktu Anda yang berharga selama berjam-jam. Setiap minggu. Solusinya adalah dengan memiliki proxy atau repositori yang diatur secara lokal dan itu membutuhkan waktu yang cukup lama untuk memperbaikinya juga.

Struktur proyek Mavens tidak terlalu cocok untuk pengembangan dengan Eclipse, dan waktu pembuatan dalam gerhana bertambah.

Akibat dari pembuatan kode dan masalah sinkronisasi, kami harus membangun kembali dari scrach lebih sering, mengurangi siklus kode / kompilasi / pengujian Anda menjadi kompilasi / websurf / sleep / die / code-cycle tanpa akhir, mengirim Anda kembali ke tahun 90-an dan Waktu kompilasi 40 menit.

Satu-satunya alasan untuk maven adalah resolusi ketergantungan, tetapi saya ingin melakukannya sesekali, tidak di setiap build.

Singkatnya, maven sangat jauh dari KISS. Dan juga, advokat cenderung menjadi tipe orang yang merayakan ekstra pada hari ulang tahun mereka ketika usia mereka adalah bilangan prima. Jangan ragu untuk memilih saya :-)

Maven hebat. Menurut saya, alasan reputasinya berkaitan dengan kurva pembelajaran yang curam. (yang akhirnya saya hampir selesai)

Dokumentasinya agak kasar untuk disimak, hanya karena rasanya ada banyak teks dan hal-hal baru yang harus dipahami sebelum mulai masuk akal. Saya mengatakan hanya waktu yang dibutuhkan agar Maven dipuji secara lebih luas.

Karena Maven adalah alat untuk mereduksi orang dewasa menjadi massa yang terisak-isak karena teror mutlak.

Kelebihan:

• Manajemen ketergantungan. Sudah beberapa tahun, rekan kerja saya dan saya tidak mengunduh dan mengelola dependensi secara manual. Ini adalah penghemat waktu yang sangat besar.
• Kemandirian IDE. Ternyata, semua IDE utama, Eclipse, IDEA dan NetBeans memiliki dukungan yang layak untuk proyek Maven sehingga pengembang kami tidak terkunci pada satu IDE tertentu.
• Garis komando. Dengan Maven, mendukung IDE simultan dan konfigurasi baris perintah sangat mudah yang bagus untuk integrasi berkelanjutan.

Kekurangan:

• Harus berinvestasi dalam mempelajari Maven. Nah, harus melakukannya. Kabar baiknya, tidak semua orang di tim harus belajar.
• Dokumentasi. Dulu menjadi masalah, sekarang berkat Sonatype dan buku mereka ( http://www.sonatype.com/products/maven/documentation/book-defguide ), situasinya jauh lebih baik.
• Kekakuan. Terkadang sulit dan membuat frustrasi melakukan hal-hal seperti yang Anda inginkan. Saran saya jangan berkelahi dan membuat Maven melakukan hal yang terbaik, membangun langsung, atau saat tersedia mojo stabil. Dalam kasus lain, kami keluar dan melakukan hal-hal baik dengan tugas Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) atau program eksternal. Favorit pribadi saya adalah Groovy plugun ( http://groovy.codehaus.org/GMaven ).

Kompetisi:

• Ant: tidak memiliki manajemen ketergantungan. Titik.
• Ivy: masih kurang dewasa dari Maven (bukannya Maven juga tidak memiliki kebiasaan). Fiturnya hampir sama, jadi tidak ada alasan yang memaksa untuk pindah. Saya melakukan beberapa upaya untuk mencobanya; semua tidak berhasil.

Intinya: semua proyek kami telah diselesaikan dengan Maven selama beberapa tahun.

Saya pikir itu memiliki reputasi buruk dengan orang-orang yang memiliki proyek paling sederhana dan paling rumit.

Jika Anda membuat satu WAR dari satu basis kode, hal itu memaksa Anda untuk memindahkan struktur proyek Anda dan secara manual mencantumkan dua dari tiga botol ke dalam file POM.

Jika Anda membuat satu EAR dari satu set sembilan prototipe file EAR dengan beberapa kombinasi dari lima file WAR, tiga EJB dan 17 alat lainnya, dependensi jars dan konfigurasi yang memerlukan penyesuaian file MANIFEST.MF dan XML dalam sumber daya yang ada selama pembuatan akhir; maka Maven sepertinya terlalu membatasi. Proyek semacam itu menjadi kekacauan profil bertingkat yang rumit, file properti, dan penyalahgunaan tujuan build Maven dan penunjukan Pengklasifikasi.

Jadi jika Anda berada di 10% terbawah dari kurva kompleksitas, itu berlebihan. Di 10% teratas dari kurva itu, Anda menggunakan jaket ketat.

Pertumbuhan Maven karena berhasil dengan baik untuk 80% menengah

Pengalaman saya menggemakan rasa frustrasi dari banyak postingan di sini. Masalah dengan Maven adalah ia membungkus dan menyembunyikan detail manajemen build dalam upayanya untuk kebaikan automagical tertinggi. Ini membuat Anda hampir tidak berdaya jika rusak.

Pengalaman saya adalah bahwa masalah apa pun dengan maven dengan cepat merosot menjadi berburu snipe multi jam melalui web file xml bersarang, dalam pengalaman yang mirip dengan saluran akar.

Saya juga bekerja di toko-toko yang sangat bergantung pada Maven, orang-orang yang menyukainya (yang menyukai aspek "tekan tombol, selesaikan semuanya") tidak memahaminya. Bangunan maven memiliki sejuta target otomatis, yang saya yakin akan berguna jika saya ingin meluangkan waktu berjam-jam untuk membaca apa yang mereka lakukan. Lebih baik 2 target yang berhasil yang Anda pahami sepenuhnya.

peringatan: terakhir bekerja dengan Maven 2 tahun lalu, mungkin lebih baik sekarang.

Seperti Glenn, saya tidak berpikir Maven memiliki reputasi yang buruk, tetapi reputasi campuran. Saya telah bekerja selama 6 bulan secara eksklusif mencoba memigrasi proyek proyek yang agak besar ke Maven dan itu dengan jelas menunjukkan batasan alat.

Menurut pengalaman saya, Maven bagus untuk:

• manajemen ketergantungan eksternal
• manajemen terpusat dari build (warisan pom)
• banyak plugin untuk banyak hal
• integrasi yang sangat baik dengan alat integrasi berkelanjutan
• kemampuan pelaporan yang sangat baik (FindBugs, PMD, Checkstyle, Javadoc, ...)

Dan ini memiliki beberapa masalah dengan:

• semua atau tidak sama sekali (sulit untuk bermigrasi perlahan ke Maven)
• dependensi kompleks, dependensi intermodules
• ketergantungan siklik (Saya tahu, desain yang buruk, tetapi kami tidak dapat memperbaiki 5 tahun dev ...)
• koherensi (rentang versi tidak berfungsi sama di semua tempat)
• bug (sekali lagi dengan rentang versi)
• build yang dapat direproduksi (kecuali jika Anda memperbaiki nomor versi dari semua plugin, Anda tidak dapat memastikan bahwa Anda akan mendapatkan build yang sama dalam 6 bulan)
• kurangnya dokumentasi (dokumennya cukup bagus untuk dasar-dasarnya, tetapi tidak banyak contoh bagaimana menangani proyek besar)

Untuk memberikan beberapa konteks, ada sekitar 30 pengembang yang mengerjakan proyek ini, dan proyek tersebut telah ada selama lebih dari 5 tahun, jadi: banyak warisan, banyak proses sudah ada, banyak alat kepemilikan khusus sudah ada. Kami memutuskan untuk mencoba bermigrasi ke Maven karena biaya pemeliharaan alat milik kami terlalu tinggi.

Saya ingin menanggapi beberapa keluhan yang dibuat di forum ini:

Maven adalah semua-atau-tidak sama sekali. Atau setidaknya sejauh yang saya tahu dari dokumentasinya. Anda tidak dapat dengan mudah menggunakan maven sebagai pengganti semut, dan secara bertahap mengadopsi fitur yang lebih canggih.

Ini tidak benar. Kemenangan besar Maven adalah menggunakannya untuk mengelola dependensi Anda dengan cara yang rasional dan jika Anda ingin melakukannya di maven dan melakukan yang lainnya di semut, Anda bisa. Begini caranya:

<?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>

Anda sekarang memiliki objek classpath bernama 'maven.classpath' yang berisi semua dependensi maven yang ditentukan dalam file pom. Yang Anda butuhkan hanyalah meletakkan jar maven ant tasks di direktori lib semut Anda.

Maven membuat proses build Anda bergantung pada koneksi jaringan Anda.

Proses pengambilan plugin dan dependensi default bergantung pada koneksi jaringan, ya, tetapi hanya untuk build awal (atau jika Anda mengubah dependensi atau plugin yang digunakan). Setelah itu semua toples di-cache secara lokal. Dan jika Anda ingin memaksa koneksi tanpa jaringan, Anda dapat memberitahu maven untuk menggunakan mode offline.

Itu memaksakan struktur yang kaku pada Anda sejak awal.

Tidak jelas apakah ini mengacu pada format file atau masalah 'konvensi versus konfigurasi'. Untuk yang terakhir, ada banyak default yang tidak terlihat seperti lokasi yang diharapkan dari file dan resource sumber java, atau kompatibilitas sumber. Tapi ini bukan kekakuan, ini menempatkan default yang masuk akal untuk Anda sehingga Anda tidak perlu mendefinisikannya secara eksplisit. Semua pengaturan dapat diganti dengan cukup mudah (meskipun untuk pemula mungkin sulit untuk menemukan dalam dokumentasi bagaimana mengubah hal-hal tertentu).

Jika Anda berbicara tentang format file, nah itu tercakup dalam tanggapan untuk bagian selanjutnya ...

Ini berbasis XML sehingga sulit dibaca seperti ANT sebelumnya.

Pertama, saya tidak melihat bagaimana Anda dapat mengeluh bahwa beberapa aspek dari sesuatu 'Tidak lebih baik daripada semut' sebagai pembenaran untuk memiliki reputasi yang buruk. Kedua, saat masih XML, format XML jauh lebih jelas. Lebih jauh, karena begitu jelasnya, jauh lebih mudah untuk membuat editor klien tebal yang masuk akal untuk POM. Saya telah melihat halaman panjang ant membangun skrip yang melompati semua tempat. Editor skrip semut build tidak akan membuatnya lebih enak, hanya daftar panjang tugas yang saling berhubungan yang disajikan dengan cara yang sedikit berbeda.

Karena itu ada beberapa keluhan yang saya lihat di sini yang memiliki atau memiliki beberapa vailiditas, makhluk terbesar

• Dokumentasi buruk / hilang
• Bangunan yang dapat direproduksi
• Integrasi Eclipse buruk
• Bug

Yang mana tanggapan saya ada dua. Pertama, Maven adalah alat yang jauh lebih muda daripada Ant atau Make, jadi Anda harus berharap bahwa ini akan membutuhkan waktu untuk mencapai tingkat kematangan aplikasi tersebut. Kedua, jika Anda tidak menyukainya, perbaiki . Ini adalah proyek open source dan menggunakannya dan kemudian mengeluh tentang sesuatu yang siapa pun dapat membantu memecahkannya tampaknya cukup bodoh bagi saya. Tidak suka dokumentasinya? Berikan kontribusi untuk membuatnya lebih jelas, lebih lengkap, atau lebih mudah diakses oleh pemula.

Masalah build yang dapat direproduksi dibagi menjadi dua masalah, rentang versi dan pembaruan plugin maven otomatis. Untuk pembaruan plugin, kecuali jika Anda memastikan ketika Anda membangun kembali proyek setahun kemudian bahwa Anda menggunakan JDK yang sama persis dan versi Ant yang sama persis, nah ini adalah masalah yang sama dengan nama yang berbeda. Untuk rentang versi, saya sarankan untuk mengerjakan plugin yang akan menghasilkan pom sementara dengan versi terkunci untuk semua dependensi langsung dan transitif dan menjadikannya bagian dari siklus rilis maven. Dengan begitu, pom build rilis Anda selalu merupakan deskripsi yang tepat dari semua dependensi.

Itu layak mendapatkan reputasi yang dimilikinya. Tidak semua orang membutuhkan struktur kaku yang menurut para pengembang Maven sesuai untuk setiap proyek. Ini sangat tidak fleksibel. Dan apa yang 'Pro' bagi banyak orang, manajemen ketergantungan, adalah IMHO 'kontra' terbesarnya. Saya benar-benar tidak nyaman dengan maven mengunduh toples dari jaringan dan kehilangan waktu tidur karena ketidaksesuaian (ya, mode offline ada, tetapi mengapa saya harus memiliki semua ratusan file xml dan checksum itu). Saya memutuskan perpustakaan mana yang saya gunakan dan banyak proyek memiliki masalah serius tentang build yang bergantung pada koneksi jaringan.

Lebih buruk lagi, ketika segala sesuatunya tidak berhasil, Anda benar-benar tersesat. Dokumentasinya payah, komunitasnya tidak mengerti.

Setahun kemudian saya ingin memperbarui ini: Saya tidak lagi memiliki opini ini tentang komunitas Maven. Saya tidak akan menulis jawaban ini jika pertanyaan itu diajukan hari ini. Saya akan menambahkan pendapat saya saat ini sebagai jawaban terpisah.

Ini adalah jawaban yang sangat subjektif, tetapi pertanyaannya tentang opini, jadi ...

Aku menyukai Maven, dan semakin menyukainya semakin aku mengetahuinya. Namun, satu hal yang memengaruhi perasaan saya tentang hal itu: komunitas maven sebagian besar berpusat di sekitar Sonatype ("perusahaan maven", tempat di mana banyak honcho Maven bekerja), dan Sonatype mendorong produk korporatnya dengan cukup agresif ke komunitas.

Contoh: Aliran twitter "Maven Book" tertaut ke pengenalan yang seharusnya untuk manajemen repositori .

Maaf, tapi "pengantar" itu adalah setengah informasi, setengah promosi penjualan untuk Nexus. Kuis pop: apakah ada manajer repo lain selain Nexus dan Nexus Pro? Juga, apa hubungannya dengan Buku Maven yang seharusnya bersumber terbuka? Oh, benar, bab tentang manajemen repositori telah dipisahkan menjadi buku terpisah ... tentang Nexus. Hah. Jika saya berkontribusi untuk buku Maven, apakah saya mendapatkan biaya referensi jika saya menyebabkan peningkatan penjualan Nexus?

Bayangkan jika Anda berpartisipasi dalam forum pengembangan Java dan jelas bahwa karyawan Sun yang mendiskusikan Java akan menggunakan setiap kesempatan yang memungkinkan untuk membicarakan NetBeans dan "NetBeans Pro". Setelah beberapa saat, perasaan komunitasnya hilang. Saya tidak pernah mengalami pengalaman seperti itu dengan Ant.

Setelah mengatakan semua itu, menurut saya Maven adalah sistem yang sangat menarik dan berguna (saya tidak menyebutnya sebagai alat, seperti Ant, Maven lebih luas dari itu) untuk konfigurasi pengembangan perangkat lunak dan manajemen pembangunan. Manajemen ketergantungan terkadang merupakan berkah dan kutukan, tetapi menyegarkan - dan tentunya bukan satu-satunya keuntungan yang ditawarkan Maven. Saya mungkin bereaksi sedikit terlalu keras terhadap Sonatype shilling, tapi menurut saya hal itu menyakitkan Maven. Saya tidak tahu apakah pendapat ini dibagikan oleh orang lain.

Saya pikir Maven mendapat reputasi buruk karena memaksakan struktur pada proyek Anda, sedangkan alat lain seperti Ant memungkinkan Anda untuk sepenuhnya menentukan struktur sesuka Anda. Setuju juga bahwa dokumentasinya buruk, tapi saya pikir terutama rap buruk yang didapat Maven adalah karena orang-orang sudah terbiasa dengan Ant.

Terlalu banyak sihir.

Karena orang yang tidak puas mengeluh sementara orang yang puas tidak mengatakan bahwa mereka puas. Maksud saya adalah bahwa ada pengguna Maven yang jauh lebih puas daripada yang tidak puas tetapi kemudian membuat lebih banyak suara. Ini adalah pola umum dari kehidupan nyata juga sebenarnya (ISP, operator telepon, transportasi, dll, dll).

Satu-satunya masalah terpenting bagi saya adalah bahwa Maven, jika tidak dikonfigurasi dengan benar, mungkin tidak menghasilkan build yang dapat diulang, karena:

• repositori jarak jauh yang tidak dapat diandalkan;
• ketergantungan pada plugin dan pustaka dengan versi SNAPSHOT atau tanpa versi.

Bandingkan ini dengan bangunan semut yang - meskipun IMO bertele-tele dan melelahkan - berfungsi karena semua stoples diperiksa secara lokal.

Bagian yang baik adalah bahwa masalahnya dapat diatasi:

• gunakan repositori maven Anda sendiri, yang telah menjadi sangat sederhana, saya menggunakan Archiva dengan hasil yang bagus;
• selalu versi dependensi Anda dengan benar. Maven telah mulai mengunci versi plugin di super-POM yang dimulai dengan 2.0.8 atau 2.0.9 dan semua dependensi Anda harus pada versi rilis.

ide bagus - implementasi yang buruk.

Saya memindahkan proyek dari Ant ke Maven baru-baru ini. Ini bekerja dengan baik pada akhirnya, tetapi saya harus menggunakan dua versi berbeda dari maven-assembly-plugin dan maven-jar-plugin di pom yang sama (mendapat dua profil) karena apa yang berfungsi di satu versi rusak di versi lain.

Jadi itu cukup memusingkan. Dokumentasi tidak selalu bagus tetapi saya harus mengakui bahwa itu relatif mudah untuk mendapatkan jawaban google.

pastikan Anda selalu menentukan versi plugin yang Anda gunakan. Jangan berharap bahwa versi baru akan kompatibel dengan versi sebelumnya.

Saya pikir kontroversi datang dari fakta bahwa maven masih berkembang dan prosesnya terkadang menyakitkan.

salam

v.

Saya suka maven. Saya telah menggunakannya sejak sebelum 1.0. Ini adalah alat yang ampuh yang secara seimbang telah menghemat banyak waktu saya, dan meningkatkan infrastruktur pengembangan saya. Tetapi saya dapat memahami rasa frustrasi yang dialami beberapa orang. Saya melihat 3 jenis frustrasi:

1. di mana penyebabnya adalah masalah nyata (misalnya POM verbose, kurangnya dokumentasi),
2. beberapa adalah informasi yang salah (misalnya "Anda harus memiliki koneksi internet untuk membangun" - tidak benar - jangan, ini dapat dihindari),
3. beberapa di antaranya dibuang di maven tetapi sebenarnya orang lain yang bersalah ("jangan tembak pembawa pesan").

Untuk kasus pertama, masalah nyata - ya, pasti, ada masalah, POM bertele-tele, dokumentasi bisa lebih baik. Namun meskipun demikian, dimungkinkan untuk mendapatkan hasil yang baik dengan maven dalam waktu cepat. Saya merasa ngeri setiap kali saya mendapatkan proyek yang dibangun dengan semut, dan mencoba mengimpor ini ke IDE saya. Perlu waktu lama untuk menyiapkan struktur direktori. dengan maven, ini hanya kasus membuka file POM di IDE.

Untuk kasus kedua, Maven itu rumit, dan kesalahpahaman adalah hal biasa. Jika maven 3 dapat menemukan cara untuk mengatasi kompleksitas ini (atau bahkan kompleksitas yang dipersepsikan) itu bagus. maven memang membutuhkan investasi yang cukup besar, tetapi, menurut pengalaman saya, investasi itu terbayar dengan sendirinya dengan cepat.

Untuk poin terakhir, saya pikir keluhan tentang ketergantungan transitif maven mungkin adalah contoh yang paling terkenal.

Ketergantungan transitif adalah sifat perangkat lunak nyata yang menggunakan penggunaan kembali. DLL Windows, paket Debian, paket java, bundel OSGi, bahkan file header C ++ termasuk semuanya memiliki ketergantungan dan mengalami masalah ketergantungan. Jika Anda memiliki dua ketergantungan, dan masing-masing menggunakan versi berbeda dari hal yang sama, maka Anda harus mencoba menyelesaikannya. Maven tidak mencoba untuk memecahkan masalah ketergantungan, melainkan membawanya ke garis depan, dan menyediakan alat untuk membantu mengelola masalah, seperti dengan melaporkan konflik dan menyediakan ketergantungan yang konsisten untuk hierarki proyek, dan pada kenyataannya memberikan kendali mutlak atas ketergantungan proyek.

Pendekatan memasukkan dependensi secara manual dengan setiap project (satu poster mengatakan dia memeriksa semua dependensi ke dalam kontrol sumber) menjalankan risiko menggunakan dependensi yang salah, seperti update yang diabaikan saat library diperbarui tanpa memeriksa update untuk dependensinya. Untuk proyek dengan ukuran berapa pun, mengelola dependensi secara manual pasti akan menyebabkan kesalahan. Dengan maven, Anda dapat mengupdate versi library yang Anda gunakan dan dependensi yang benar disertakan. Untuk manajemen perubahan, Anda dapat membandingkan set dependensi lama (untuk proyek Anda secara keseluruhan) dengan set baru, dan setiap perubahan dapat dengan cermat diteliti, diuji, dll.

Maven bukanlah penyebab masalah ketergantungan, tetapi membuatnya lebih terlihat. Dalam menangani masalah dependensi, maven membuat dependensi "tweak" menjadi eksplisit (perubahan pada POM Anda yang menggantikan dependensi), bukan implisit, seperti halnya dengan toples yang dikelola secara manual dalam kontrol versi, di mana jars hanya ada, tanpa ada mendukung cuaca mereka adalah ketergantungan yang benar atau tidak.

Saya percaya bahwa Maven memiliki reputasi yang buruk karena sebagian besar pencela belum mengamati kombinasi Maven + Hudson + Sonar . Jika ya, mereka akan bertanya "bagaimana saya memulai"?

Beberapa hewan peliharaan saya kesal dengan Maven:

• Definisi XML sangat kikuk dan bertele-tele. Pernahkah mereka mendengar tentang atribut?

• Dalam konfigurasi defaultnya, itu selalu menjelajahi 'net di setiap operasi. Terlepas dari apakah ini berguna untuk apa pun, tampaknya sangat konyol membutuhkan akses Internet untuk "bersih".

• Sekali lagi di default, jika saya tidak berhati-hati untuk menentukan nomor versi yang tepat, itu akan menarik pembaruan terbaru dari 'net, terlepas dari apakah versi terbaru ini memperkenalkan kesalahan ketergantungan. Dengan kata lain, Anda bergantung pada belas kasihan manajemen ketergantungan orang lain.

• Solusi untuk semua akses jaringan ini adalah mematikannya dengan menambahkan -oopsi. Tetapi Anda harus ingat untuk mematikannya jika Anda benar-benar ingin melakukan pembaruan ketergantungan!

• Solusi lain adalah menginstal server "kontrol sumber" Anda sendiri untuk dependensi. Kejutan: Sebagian besar project sudah memiliki kontrol sumber, hanya saja yang berfungsi tanpa penyiapan tambahan!

• Build Maven sangat lambat. Mengotak-atik pembaruan jaringan meredakan ini, tetapi build Maven masih lambat. Dan sangat bertele-tele.

• Plugin Maven (M2Eclipse) berintegrasi paling buruk dengan Eclipse. Eclipse terintegrasi cukup lancar dengan perangkat lunak kontrol versi dan dengan Ant. Integrasi Maven sangat kikuk dan jelek jika dibandingkan. Apakah saya menyebutkan lambat?

• Maven terus menjadi buggy. Pesan kesalahan tidak membantu. Terlalu banyak pengembang yang menderita karena ini.

Pertanyaan bagus. Saya baru saja memulai proyek besar di tempat kerja dan bagian dari proyek sebelumnya adalah memperkenalkan modularitas ke basis kode kami.

Saya pernah mendengar hal-hal buruk tentang maven. Faktanya, hanya itu yang pernah saya dengar tentang itu. Saya melihat untuk memperkenalkannya untuk menyelesaikan mimpi buruk ketergantungan yang saat ini kami alami. Masalah yang saya lihat dengan Maven adalah strukturnya cukup kaku, yaitu Anda harus menyesuaikan dengan tata letak proyeknya agar dapat bekerja untuk Anda.

Saya tahu apa yang akan dikatakan kebanyakan orang - Anda tidak harus menyesuaikan diri dengan strukturnya. Memang itu benar tetapi Anda tidak akan mengetahuinya sampai Anda melewati kurva pembelajaran awal di mana Anda telah menginvestasikan terlalu banyak waktu untuk pergi dan membuang semuanya.

Semut banyak digunakan akhir-akhir ini, dan saya menyukainya. Mempertimbangkan hal itu, saya menemukan manajer dependensi yang kurang dikenal bernama Apache Ivy . Ivy terintegrasi dengan sangat baik ke dalam Ant dan cepat dan mudah untuk mendapatkan pengaturan pengambilan JAR dasar dan berfungsi. Manfaat lain dari Ivy adalah sangat kuat namun cukup transparan; Anda dapat mentransfer build menggunakan mekanisme seperti scp atau ssh dengan cukup mudah; Pengambilan ketergantungan 'rantai' melalui sistem file atau repositori jarak jauh (kompatibilitas repo Maven adalah salah satu fiturnya yang populer).

Itu semua mengatakan, saya merasa sangat frustasi untuk menggunakannya pada akhirnya - dokumentasinya banyak, tetapi ditulis dalam bahasa Inggris yang buruk yang dapat menambah frustrasi saat debugging atau mencoba mencari tahu apa yang salah.

Saya akan mengunjungi kembali Apache Ivy di beberapa titik selama proyek ini dan saya berharap dapat berfungsi dengan baik. Satu hal yang dilakukannya adalah memungkinkan kami sebagai tim untuk menentukan perpustakaan apa yang kami andalkan dan mendapatkan daftar yang terdokumentasi.

Pada akhirnya, saya pikir semuanya tergantung pada bagaimana Anda bekerja sebagai individu / tim dan apa yang Anda butuhkan untuk menyelesaikan masalah ketergantungan Anda.

Anda mungkin menemukan sumber daya berikut yang berkaitan dengan Ivy berguna:

• Perbandingan Apache Ivy vs Maven 2
• FAQ Apache Ivy
• Daftar fitur Apache Ivy

Saya suka Maven - ini meningkatkan produktivitas, dan saya sangat senang karena saya tidak lagi menggunakan Ant (Fiuh!)

Tetapi jika saya bisa mengubah hal-hal itu akan menjadi:

1. Jadikan pom.xmlfile tidak terlalu bertele-tele
2. Buat lebih mudah untuk menyertakan .jars bukan dari repositori.

Ada banyak alasan mengapa orang tidak menyukai Maven, tapi terus terang saja mereka sangat subjektif . Maven hari ini dengan beberapa buku bagus (dan gratis), dokumentasi yang lebih baik, kumpulan plugin yang lebih besar, dan banyak proyek referensial yang berhasil dibangun tidak sama dengan Maven satu atau dua tahun lalu.

Menggunakan Maven dalam proyek sederhana sangatlah mudah, dengan proyek yang lebih besar / rumit diperlukan lebih banyak pengetahuan dan pemahaman yang lebih dalam tentang filosofi Maven - mungkin di tingkat perusahaan posisi untuk guru Maven seperti admin jaringan. Sumber utama pernyataan kebencian Maven seringkali adalah ketidaktahuan .

Masalah lain untuk Maven adalah kurangnya fleksibilitas seperti misalnya di Ant. Tapi ingat Maven memiliki seperangkat konvensi - berpegang teguh pada mereka tampaknya sulit pada awalnya, tetapi pada akhirnya sering menyelamatkan dari masalah.

Kesuksesan Maven saat ini membuktikan nilainya. Tentu saja tidak ada yang sempurna dan Maven memiliki beberapa kekurangan dan keunikannya, tetapi menurut saya Maven perlahan mempengaruhi lawannya.

Saya tidak akan mengatakan itu memiliki reputasi yang buruk karena memiliki reputasi campuran. Jika proyek Anda mengikuti paradigma "konvensi atas konfigurasi" yang dianjurkan oleh Maven, maka Anda bisa mendapatkan banyak manfaat darinya. Jika proyek Anda tidak sesuai dengan pandangan dunia Maven, maka itu bisa menjadi beban.

Untuk itu, jika Anda memiliki kendali atas proyek tersebut, maka Maven mungkin adalah cara yang tepat. Tetapi jika Anda tidak melakukannya dan tata letaknya ditentukan oleh seseorang yang bukan penggemar Maven, itu mungkin lebih merepotkan daripada nilainya. Proyek Maven yang paling bahagia mungkin adalah proyek yang dimulai sebagai proyek Maven.

Bagi saya, ada banyak kelebihan dan kekurangan penggunaan maven vs semut untuk proyek-proyek internal. Namun untuk proyek open source, saya pikir Maven memiliki pengaruh besar dalam membuat banyak proyek lebih mudah dibangun. Belum lama ini dibutuhkan waktu berjam-jam untuk mendapatkan rata-rata proyek OSS Java (berbasis semut) untuk dikompilasi, harus menetapkan banyak variabel, mengunduh proyek dependen, dll.

Anda dapat melakukan apa saja dengan Maven yang dapat Anda lakukan dengan Ant, tetapi jika Ant tidak mendorong standar apa pun, Maven sangat menyarankan Anda untuk mengikuti strukturnya, atau itu akan lebih berhasil. Benar, beberapa hal sulit diatur dengan Maven yang akan mudah dilakukan dengan Ant, tetapi hasil akhirnya hampir selalu sesuatu yang lebih mudah untuk dibangun dari sudut pandang orang yang hanya ingin memeriksa sebuah proyek dan pergi.

Jika Anda akan mempertaruhkan bisnis atau pekerjaan Anda pada sebuah proyek pengembangan, Anda ingin mengendalikan fondasi - yaitu sistem build. Dengan Maven, Anda tidak memegang kendali. Ini bersifat deklaratif dan buram. Pengembang maven-framework tidak tahu bagaimana membangun sistem yang transparan atau intuitif dan ini terlihat jelas dari keluaran log dan dokumentasinya.

Manajemen ketergantungan sangat menggoda karena bisa saja sama dengan Anda beberapa saat pada awal proyek tetapi berhati-hatilah, ini pada dasarnya rusak dan pada akhirnya akan menyebabkan banyak sakit kepala. Jika dua dependensi memiliki dependensi sementara yang tidak kompatibel, Anda akan diblokir oleh kerumitan tikus yang akan merusak build untuk seluruh tim Anda dan memblokir pengembangan selama berhari-hari. Proses build dengan Maven juga terkenal tidak konsisten untuk developer yang berbeda di tim Anda karena status repositori lokalnya yang tidak konsisten. Bergantung pada kapan pengembang menciptakan lingkungan mereka, atau proyek lain apa yang mereka kerjakan, mereka akan memiliki hasil yang berbeda. Anda akan menemukan bahwa Anda menghapus seluruh repositori lokal dan meminta Maven mengunduh ulang toples jauh lebih sering daripada saat pertama kali menyiapkan untuk cabang dev. Saya yakin OSGI adalah inisiatif yang mencoba untuk memperbaiki masalah mendasar ini. Saya akan mengatakan bahwa mungkin jika sesuatu perlu menjadi begitu kompleks, premis dasarnya salah.

Saya telah menjadi pengguna / korban maven selama lebih dari 5 tahun sekarang dan saya harus mengatakan bahwa itu akan menghemat lebih banyak waktu untuk hanya memeriksa ketergantungan Anda ke dalam repositori sumber Anda dan menulis tugas semut yang bagus dan sederhana. Dengan semut, Anda tahu PERSIS apa yang dilakukan sistem build Anda.

Saya telah mengalami banyak sekali kehilangan waktu berminggu-minggu di beberapa perusahaan yang berbeda karena masalah Maven.

Saya baru-baru ini mencoba menghidupkan kembali proyek GWT / Maven / Eclipse lama dan 2 minggu dari semua waktu luang saya nanti, saya masih tidak bisa membuatnya dibangun secara konsisten. Saatnya untuk memotong kerugian saya dan mengembangkan menggunakan semut / gerhana menurut saya ...

Jawaban singkatnya: Saya merasa sangat sulit untuk mempertahankan sistem build Maven, dan saya ingin beralih ke Gradle secepat mungkin.

Saya telah bekerja dengan Maven selama lebih dari empat tahun. Saya menyebut diri saya ahli dalam membangun sistem karena dalam (setidaknya) lima perusahaan terakhir yang pernah saya masuki, saya telah melakukan renovasi besar-besaran pada infrastruktur pembangunan / penerapan.

Beberapa pelajaran yang saya pelajari:

• Sebagian besar pengembang cenderung tidak menghabiskan banyak waktu untuk memikirkan tentang membangun sistem; akibatnya, bangunan tersebut berubah menjadi spageti yang berantakan, tetapi mereka sangat menghargainya saat kekacauan itu dibersihkan dan dirasionalisasi.
• Dalam menangani kompleksitas, saya lebih suka memiliki sistem transparan yang mengekspos kompleksitas (seperti Ant) daripada sistem yang mencoba membuat hal-hal kompleks menjadi sederhana dengan memberlakukan batasan yang kaku, seperti Maven. Pikirkan Linux vs. Windows.
• Maven memiliki banyak lubang dalam fungsionalitas yang membutuhkan solusi Bizantium. Ini mengarah ke file POM yang tidak dapat dipahami dan tidak dapat dikelola.
• Ant sangat fleksibel dan dapat dimengerti, tetapi file Ant juga bisa menjadi sangat besar, karena levelnya sangat rendah.
• Untuk proyek penting apa pun, pengembang harus membuat struktur build / deploy mereka sendiri di luar yang disediakan alat; kesesuaian struktur dengan proyek banyak berkaitan dengan kemudahan perawatannya. Alat terbaik akan mendukung Anda dalam menciptakan struktur dan bukan melawan Anda.

Saya telah mempelajari Gradle sedikit dan sepertinya Gradle berpotensi menjadi yang terbaik dari kedua dunia, memungkinkan campuran deskripsi build deklaratif dan prosedural.

Ini lebih rumit daripada bahasa yang Anda gunakan untuk menulis proyek Anda. Mengkonfigurasi dengan benar lebih sulit daripada pemrograman sebenarnya.

Saya telah berjuang melalui sebagian besar / semua hal negatif yang disebutkan di sini, dan keberatan serupa dari rekan satu tim, dan setuju dengan semuanya. Tetapi saya telah bertahan dan akan terus melakukannya dengan berpegang teguh pada satu tujuan yang hanya dapat dicapai oleh maven (atau mungkin gradle).

Jika Anda mengoptimalkan untuk rekan ( pengembang sumber terbuka ), ant / make / apa saja bisa digunakan. Jika Anda mengirimkan fungsionalitas ke non-peer ( pengguna ), hanya maven / gradle / etc yang akan melakukannya.

Hanya maven yang memungkinkan Anda merilis bundel kecil kode sumber + pom (tidak ada lib / binary dependency jars dengan nama samar dan tidak ada info ketergantungan) dengan layout proyek standar yang terdokumentasi dengan baik yang dapat dimuat oleh IDE oleh seseorang yang belum diserap konvensi tata letak istimewa pengembang. Dan ada prosedur penginstalan satu tombol (mvn install) yang membangun segalanya sambil memperoleh dependensi yang hilang.

Hasilnya adalah jalan mudah yang dapat diikuti pengguna untuk menemukan jalan mereka ke dalam kode, di mana pom dapat mengarahkan mereka ke dokumentasi yang relevan.

Terlepas dari persyaratan (sangat diperlukan) itu, saya tidak menyukai Pakar sebanyak siapa pun.