Mengapa pakar? Apa manfaatnya? [Tutup]


131

Apa manfaat utama menggunakan pakar sihir dibandingkan dengan katakanlah semut? Tampaknya lebih menjengkelkan daripada alat yang bermanfaat. Saya menggunakan maven 2, dengan Java Eclipse EE biasa (tanpa m2eclipse), dan kucing jantan.

Pendukung pakar percaya itu

  1. Maven memungkinkan Anda mendapatkan dependensi paket dengan mudah

  2. Maven memaksa Anda untuk memiliki struktur direktori standar

Dalam pengalaman saya

  1. Mencari tahu dependensi paket benar-benar tidak sulit. Anda jarang melakukannya. Mungkin sekali selama pengaturan proyek dan beberapa lagi selama peningkatan. Dengan maven, Anda akan akhirnya memperbaiki dependensi yang tidak cocok, pom yang ditulis dengan buruk, dan melakukan pengecualian paket.

  2. Siklus FIX-COMPILE-DEPLOY-DEBUG yang lambat, yang membunuh produktivitas. Ini keluhan utama saya. Anda membuat perubahan, Anda harus menunggu untuk membangun pakar untuk menendang dan menunggu untuk digunakan. Tidak ada penyebaran panas sama sekali.

Atau apakah saya salah melakukannya? Tolong arahkan saya ke arah yang benar, saya semua telinga.


1
Saya benar-benar tertarik dengan poin 2. Apakah ada orang lain yang memperhatikan siklus perbaikan-kompilasi-pemasangan yang lambat? atau semua orang agak tahu tetapi tetap diam karena maven adalah yang terbaik yang kita punya / hal yang paling umum / paling keren. Menciptakan perang / telinga untuk dikerahkan sudah cukup buruk, pakar membuat itu lebih buruk. Dibutuhkan secara kasar 5 detik pada mesin saya untuk melihat perubahan jsp pada proyek pakar, pada struktur direktori yang meledak? kurang dari 1 detik Saya dapat menyimpan beberapa kali, dan hanya mengkompilasi perubahan terbaru, di pakar? setiap save memicu build.
trix

Mungkin pakar bukan masalah di sini, tetapi dukungan IDE / plugin? Namun, pakar sudah ada untuk beberapa waktu, jika kita tidak bisa melakukannya dengan benar, haruskah kita memindahkan / menemukan / mengusulkan sesuatu yang lain? selain Ivy
trix

2
@ Javid Sementara judul pertanyaannya terlihat serupa, isi pertanyaannya adalah IMO yang berbeda dan saya tidak menganggapnya sebagai penipuan.
Pascal Thivent


Untuk sesaat kedengarannya seperti kamu berbicara tentang NuGet ...
micahhoover

Jawaban:


108

Mencari tahu dependensi paket benar-benar tidak sulit. Anda jarang melakukannya. Mungkin sekali selama pengaturan proyek dan beberapa lagi selama peningkatan. Dengan maven, Anda akan akhirnya memperbaiki dependensi yang tidak cocok, pom yang ditulis dengan buruk, dan melakukan pengecualian paket.

Tidak sulit ... untuk proyek mainan. Tetapi proyek yang saya kerjakan memiliki banyak, sangat banyak, dari mereka, dan saya sangat senang mendapatkannya secara transitif, untuk memiliki skema penamaan standar untuk mereka. Mengelola semua ini secara manual dengan tangan akan menjadi mimpi buruk.

Dan ya, kadang-kadang Anda harus bekerja pada konvergensi dependensi. Tapi pikirkan dua kali, ini tidak melekat pada Maven, ini melekat pada sistem yang menggunakan dependensi (dan saya berbicara tentang dependensi Java secara umum di sini).

Jadi dengan Ant, Anda harus melakukan pekerjaan yang sama kecuali Anda harus melakukan semuanya secara manual: meraih beberapa versi proyek A dan dependensinya, meraih beberapa versi proyek B dan dependensinya, mencari tahu sendiri versi persis apa yang mereka gunakan, memeriksa bahwa mereka tidak tumpang tindih, memeriksa bahwa mereka tidak kompatibel, dll. Selamat datang di neraka.

Di sisi lain, Maven mendukung manajemen dependensi dan akan mengambilnya secara transitif untuk saya dan memberi saya alat yang saya butuhkan untuk mengelola kompleksitas yang melekat pada manajemen dependensi : Saya dapat menganalisis pohon dependensi, mengontrol versi yang digunakan dalam dependensi transitif, mengecualikan beberapa dari mereka jika diperlukan, mengontrol konvergensi lintas modul, dll. Tidak ada keajaiban. Tetapi setidaknya Anda memiliki dukungan.

Dan jangan lupa bahwa manajemen ketergantungan hanya sebagian kecil dari apa yang ditawarkan Maven, ada lebih banyak (bahkan tidak menyebutkan alat-alat lain yang terintegrasi dengan baik dengan Maven, misalnya Sonar ).

Siklus FIX-COMPILE-DEPLOY-DEBUG yang lambat, yang membunuh produktivitas. Ini keluhan utama saya. Anda membuat perubahan, Anda harus menunggu untuk membangun pakar untuk menendang dan menunggu untuk digunakan. Tidak ada penyebaran panas sama sekali.

Pertama, mengapa Anda menggunakan Maven seperti ini? Bukan saya. Saya menggunakan IDE saya untuk menulis tes, kode sampai lulus, refactor, menyebarkan, menyebarkan panas dan menjalankan build Maven lokal ketika saya selesai, sebelum melakukan, untuk memastikan saya tidak akan merusak build yang berkelanjutan.

Kedua, saya tidak yakin menggunakan Ant akan membuat segalanya lebih baik. Dan menurut pengalaman saya, pembuatan Maven modular menggunakan dependensi biner memberi saya waktu pembuatan yang lebih cepat daripada build Ant monolitik biasa. Pokoknya, lihat Maven Shell untuk siap (kembali) menggunakan lingkungan Maven (yang luar biasa).

Jadi pada akhirnya, dan saya minta maaf untuk mengatakannya, bukan Maven yang benar-benar membunuh produktivitas Anda, melainkan Anda menyalahgunakan alat Anda. Dan jika Anda tidak senang dengan itu, apa yang bisa saya katakan, jangan menggunakannya. Secara pribadi, saya menggunakan Maven sejak 2003 dan saya tidak pernah melihat ke belakang.


@ Pascal, dapatkah Anda memberi tahu alat apa yang Anda gunakan? IDE, plugin, dll. Apakah Anda memberi tahu kami bahwa jika saya mengubah file .properties, atau file jsp, ini akan menjadi panas digunakan tanpa melakukan pembuatan maven? (mungkin penyebaran panas bukan istilah yang benar di sini). Saya tidak jelas dengan apa yang saya maksudkan dengan semut. Maksud saya menggunakan direktori meledak standar selama pengembangan dan menggunakan semut untuk membuat perang / telinga sebelum rilis. Untuk direktori yang meledak aturannya sederhana, salin / kompilasi file dari src ke kelas dan jangan menyentuh yang lain.
trix

lanjutan ... Namun, dalam proyek saya, apa yang digunakan ke kucing jantan adalah toples modul. Jika saya mengubah .jsp, bukankah pakar harus membangun kembali guci itu?
trix

4
Anda harus mengakui, sebagian besar proyek adalah proyek mainan, alias dependensi sederhana. Itu hanya hukum statistik.
trix

2
@trix, tentang semut penyebaran panas vs maven: jika Anda tidak melakukan semut membangun untuk penyebaran panas, mengapa Anda menggunakan Maven untuk hal yang sama? Saya kira jika Anda menggunakan semut untuk hal yang sama, itu akan memakan waktu minimal yang sama ... bukan?
Reddy

2
Jadi Pascal, dapatkah Anda memberi tahu kami bagaimana Anda memiliki proyek yang dikonfigurasikan ke alam Maven dan tidak menggunakan proses pembangunan untuk digunakan? Ini adalah poin 2 dari pertanyaan awal. Saya bertanya-tanya bagaimana cara melakukannya, jadi sangat menghargai jika Anda dapat memberi kami penjelasan yang jelas.

20

Maven dapat dianggap sebagai alat pengembangan proyek yang lengkap tidak hanya membangun alat seperti Ant. Anda harus menggunakan Eclipse IDE dengan plugin maven untuk memperbaiki semua masalah Anda.

Berikut adalah beberapa keuntungan dari Maven, dikutip dari Manfaat menggunakan halaman Maven :

Henning

  • setup proyek cepat, tidak ada file build.xml yang rumit, hanya POM dan pergi
  • semua pengembang dalam proyek menggunakan dependensi jar yang sama karena POM terpusat.
  • mendapatkan sejumlah laporan dan metrik untuk proyek "gratis"
  • mengurangi ukuran distribusi sumber, karena guci dapat ditarik dari lokasi pusat

Emmanuel Venisse

  • banyak tujuan tersedia sehingga tidak perlu untuk mengembangkan beberapa bagian proses pembangunan spesifik yang bertentangan dengan ANT kita dapat menggunakan kembali tugas ANT yang ada dalam proses pembangunan dengan plugin antrun

Jesse Mcconnell

  • Mempromosikan desain kode yang modular. dengan membuatnya mudah untuk mengelola proyek mulitple memungkinkan desain untuk ditata menjadi beberapa bagian logis, menenun bagian-bagian ini bersama-sama melalui penggunaan pelacakan ketergantungan pada file pom.
  • Menegakkan desain kode modular. mudah untuk membayar lipervice ke kode modular, tetapi ketika kode tersebut dalam proyek kompilasi terpisah tidak mungkin untuk menyilangkan referensi penyerbukan antara modul kode kecuali Anda secara khusus mengizinkannya dalam manajemen dependensi Anda ... tidak ada 'Saya akan lakukan saja ini sekarang dan perbaiki implementasi nanti.
  • Manajemen Ketergantungan dinyatakan dengan jelas. dengan mekanisme manajemen dependensi Anda harus mencoba untuk mengacaukan versi tabung Anda ... tidak ada masalah klasik 'versi mana dari wadah penjual ini adalah ini?' Dan pengaturannya pada proyek yang ada merobek bagian atas dari kekacauan yang ada jika ada ketika Anda dipaksa untuk membuat versi 'tidak dikenal' dalam repositori Anda untuk mendapatkan sesuatu dan menjalankan ... itu atau berbohong kepada diri sendiri bahwa Anda tahu versi sebenarnya dari ABC.jar.
  • siklus hidup yang diketik dengan kuat ada siklus hidup yang sangat kuat yang ditentukan oleh sistem perangkat lunak sejak permulaan pembangunan hingga akhir ... dan pengguna diizinkan untuk mencampur dan mencocokkan sistem mereka dengan siklus hidup alih-alih mengacak-acak siklus hidup mereka sendiri. ini memiliki manfaat tambahan yang memungkinkan orang untuk berpindah dari satu proyek ke proyek lainnya dan berbicara menggunakan kosakata yang sama dalam hal membangun perangkat lunak

Vincent Massol

  • Momentum yang lebih besar: Semut sekarang merupakan warisan dan tidak bergerak maju. Maven terus maju cepat dan ada potensi memiliki banyak alat bernilai tinggi di sekitar Maven (CI, proyek Dashboard, integrasi IDE, dll).

5
Sementara voting turun tolong berikan alasan, itu bukan aturan etis tetapi mengatakan tentang stackoverflow.
YoK

1
Tidak ada yang salah dengan referensi tetapi Anda benar-benar harus memperjelas bahwa konten itu bukan milik Anda.
Pascal Thivent

Terima kasih. Saya akan memastikan bahwa saya mengutipnya selain hanya menyebutkan dari mana referensi itu berasal. baru berusia 30 hari yang aneh di stackoverflow dan masih belajar seni :).
YoK

11

Menemukan ketergantungan untuk proyek-proyek kecil tidaklah sulit. Tetapi begitu Anda mulai berurusan dengan pohon dependensi dengan ratusan dependensi, hal-hal dapat dengan mudah lepas kendali. (Saya berbicara dari pengalaman di sini ...)

Poin lainnya adalah jika Anda menggunakan IDE dengan kompilasi tambahan dan dukungan Maven (seperti Eclipse + m2eclipse), maka Anda harus dapat mengatur edit / compile / hot deploy dan test.

Saya pribadi tidak melakukan ini karena saya tidak mempercayai mode perkembangan ini karena pengalaman buruk di masa lalu (sebelum Maven). Mungkin seseorang dapat berkomentar apakah ini benar-benar berfungsi dengan Eclipse + m2eclipse.


Seseorang bisa mulai dengan pakar untuk mendapatkan semua dependensi kemudian menyalin dependensi ke proyeknya, kan?
trix

2
Saya kira kamu bisa. Tapi itu akan mungkin rusak jika Anda memperbarui dependensi proyek Anda ... atau jika proyek Anda bergantung pada snapshot.
Stephen C

Maksud saya punya 2 proyek, satu-satunya tujuan proyek pakar adalah untuk mendapatkan dependensi. Gunakan kontrol versi untuk melacak perubahan antara pembaruan ketergantungan. Saya tetap melakukan ini, supaya saya bisa melihat perubahan, kalau-kalau itu merusak bangunan saya.
trix

4
Ughh. Bukan itu cara Maven dirancang untuk digunakan. Salah satu manfaat besar Maven adalah menghindari memeriksa pustaka dependen ke dalam kontrol versi. Dengan pendekatan Anda, Anda akan mengacaukan VCS Anda dengan banyak versi dari banyak file biner. Dan beberapa VCS sangat buruk dalam menangani file biner.
Stephen C

2
Secara umum Anda belajar cara sulit untuk menjadi sangat lelah dari segala jenis sihir ketika menulis program: -S
Thorbjørn Ravn Andersen

9

Maven adalah salah satu alat di mana Anda harus benar-benar memutuskan di muka bahwa Anda menyukainya dan ingin menggunakannya, karena Anda akan menghabiskan cukup banyak waktu untuk mempelajarinya, dan setelah membuat keputusan tersebut sekali dan untuk semua akan memungkinkan Anda untuk melewati semua jenis keraguan saat belajar (karena Anda suka dan ingin menggunakannya)!

Kebaktian yang kuat membantu di banyak tempat - seperti Hudson yang dapat melakukan keajaiban dengan proyek Maven - tetapi mungkin sulit untuk melihat pada awalnya.

sunting: Pada 2016 Maven adalah satu-satunya alat Java build di mana ketiga IDE utama dapat menggunakan sumber di luar kotak. Dengan kata lain, menggunakan pakar membuat agnostik IDE-build Anda. Ini memungkinkan misalnya menggunakan profil Netbeans bahkan jika Anda biasanya bekerja dalam gerhana


1
Dan yang sebaliknya juga benar, banyak orang datang ke pakar dengan kebencian yang sudah terbentuk sebelumnya, karena itu bukan semut, dll.
Goibniu

Sebaliknya? Maksudmu?
Thorbjørn Ravn Andersen

9

Keuntungan Maven dibandingkan semut cukup sedikit. Saya mencoba merangkumnya di sini.

Convention over Configuration
Maven menggunakan pendekatan khusus untuk tata letak proyek dan startup, yang membuatnya mudah untuk hanya melompat dalam proyek. Biasanya hanya dibutuhkan checkount dan perintah pakar untuk mendapatkan artefak proyek.

Modularisasi
Proyek Konvensi proyek menyarankan (atau lebih baik, memaksa) pengembang untuk memodulasi proyek. Alih-alih proyek monolitik Anda sering dipaksa untuk membagi proyek Anda dalam sub-komponen yang lebih kecil, yang membuatnya lebih mudah men-debug dan mengelola keseluruhan struktur proyek

Manajemen Ketergantungan dan Siklus Hidup Proyek
Secara keseluruhan, dengan konfigurasi SCM yang baik dan repositori internal, manajemen dependensi cukup mudah, dan Anda sekali lagi dipaksa untuk berpikir dalam hal Siklus Hidup Proyek - versi komponen, manajemen rilis dan sebagainya. Sedikit lebih kompleks daripada semut, tapi sekali lagi, peningkatan kualitas proyek.

Apa yang salah dengan pakar sihir?
Maven tidak mudah. Siklus build (apa yang dilakukan dan kapan) tidak begitu jelas dalam POM. Juga, beberapa masalah muncul dengan kualitas komponen dan ketergantungan yang hilang dalam repositori publik.
Pendekatan terbaik (bagi saya) adalah memiliki repositori internal untuk caching (dan menjaga) dependensi di sekitar, dan menerapkan untuk melepaskan manajemen komponen. Untuk proyek yang lebih besar dari proyek sampel dalam buku, Anda akan berterima kasih kepada pakar sebelum atau sesudah


6

Maven dapat memberikan manfaat untuk proses pembangunan Anda dengan menerapkan konvensi dan praktik standar untuk mempercepat siklus pengembangan Anda sementara pada saat yang sama membantu Anda mencapai tingkat kesuksesan yang lebih tinggi. Untuk tampilan yang lebih rinci tentang bagaimana Maven dapat membantu Anda dengan proses pengembangan Anda, lihat Manfaat Menggunakan Maven.


3

Maven adalah alat manajemen proyek yang kuat yang didasarkan pada POM (model objek proyek). Ini digunakan untuk membangun proyek, ketergantungan dan dokumentasi. Ini menyederhanakan proses pembuatan seperti ANT. Tapi itu terlalu maju daripada ANT. Maven membantu mengelola- Bangun, Dokumentasi, Pelaporan, SCM, Rilis, Distribusi. - Repositori maven adalah direktori file JAR yang dipaket dengan file pom.xml. Maven mencari dependensi dalam repositori.


2

Saya tidak pernah menemukan poin 2? Bisakah Anda menjelaskan mengapa menurut Anda hal ini memengaruhi penerapan dengan cara apa pun. Jika sesuatu pakar memungkinkan Anda untuk menyusun proyek Anda dengan cara modularised yang benar-benar memungkinkan perbaikan panas untuk bug di tingkat tertentu, dan memungkinkan pengembangan independen API dari sisa proyek misalnya.

Ada kemungkinan bahwa Anda mencoba menjejalkan semuanya ke dalam satu modul, dalam hal ini masalahnya bukan benar-benar pakar, tetapi cara Anda menggunakannya.


Saya menggunakan gee polos eclipse, maven 2 dan kucing jantan. Jelas aplikasi web. Jika saya mengubah file properti, atau jsp, untuk melihat perubahan saya pada kucing jantan, maven harus melakukan build-nya, membuat perang / telinga dan menggunakan untuk kucing jantan. Ini lambat dibandingkan jika saya menggunakan struktur direktori yang meledak.
trix

1
@trix Hot deploy di bawah Eclipse with Tomcat berfungsi. Kamu melakukannya dengan salah.
Pascal Thivent

0

Seharusnya ini komentar, tapi panjangnya tidak pas, jadi saya mempostingnya sebagai jawaban.

Semua manfaat yang disebutkan dalam jawaban lain dapat dicapai dengan cara yang lebih sederhana daripada menggunakan pakar. Misalnya, jika Anda baru mengenal suatu proyek, Anda tetap akan menghabiskan lebih banyak waktu untuk membuat arsitektur proyek, menggabungkan komponen, mengkode daripada mengunduh guci dan menyalinnya ke folder lib. Jika Anda berpengalaman dalam domain Anda, maka Anda sudah tahu bagaimana memulai proyek dengan pustaka apa. Saya tidak melihat manfaat menggunakan pakar, terutama ketika itu menimbulkan banyak masalah saat secara otomatis melakukan "manajemen ketergantungan".

Saya hanya memiliki pengetahuan tingkat menengah maven, tetapi saya katakan, saya telah melakukan proyek besar (seperti ERP) tanpa menggunakan maven.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.