Perbedaan antara Semut dan Maven [ditutup]


180

Bisakah seseorang memberi tahu saya perbedaan antara Semut dan Maven? Saya tidak pernah menggunakan keduanya. Saya mengerti bahwa mereka digunakan untuk mengotomatisasi pembangunan proyek-proyek Java, tetapi saya tidak tahu harus mulai dari mana.


4
Karena jawaban didominasi oleh pendukung Maven, saya ingin sedikit menyeimbangkannya. Lihat jawaban ini misalnya stackoverflow.com/questions/1306579/…
Petr Gladkikh

4
Meskipun ini tidak secara langsung menjawab pertanyaan membandingkan Ant vs Maven, masukan saya adalah melihat menggunakan Gradle, yang dapat memberi Anda akses ke Ant dan Maven secara bersamaan. gradle.org

Jawaban:


218

Dalam Maven: The Definitive Guide , saya menulis tentang perbedaan antara Maven dan Semut dalam pengantar judul bagian adalah "Perbedaan Antara Semut dan Maven" . Inilah jawaban yang merupakan kombinasi dari info dalam pengantar itu dengan beberapa catatan tambahan.

Perbandingan Sederhana

Saya hanya menunjukkan ini kepada Anda untuk mengilustrasikan gagasan bahwa, pada tingkat paling dasar, Maven memiliki konvensi bawaan. Ini file semut build yang sederhana:

<project name="my-project" default="dist" basedir=".">
    <description>
        simple example build file
    </description>   
    <!-- set global properties for this build -->   
    <property name="src" location="src/main/java"/>
    <property name="build" location="target/classes"/>
    <property name="dist"  location="target"/>

    <target name="init">
      <!-- Create the time stamp -->
      <tstamp/>
      <!-- Create the build directory structure used by compile -->
      <mkdir dir="${build}"/>   
    </target>

    <target name="compile" depends="init"
        description="compile the source " >
      <!-- Compile the java code from ${src} into ${build} -->
      <javac srcdir="${src}" destdir="${build}"/>  
    </target>

    <target name="dist" depends="compile"
        description="generate the distribution" >
      <!-- Create the distribution directory -->
      <mkdir dir="${dist}/lib"/>

      <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file
-->
      <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>

   <target name="clean"
        description="clean up" >
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
 </project>

Dalam contoh Ant sederhana ini, Anda dapat melihat bagaimana Anda harus memberi tahu Ant apa yang harus dilakukan. Ada tujuan kompilasi yang mencakup tugas javac yang mengkompilasi sumber di direktori src / main / java ke direktori target / kelas. Anda harus memberi tahu Ant di mana sumber Anda berada, di mana Anda ingin bytecode yang dihasilkan disimpan, dan bagaimana mengemas semua ini ke dalam file JAR. Meskipun ada beberapa perkembangan terbaru yang membantu membuat Ant menjadi kurang prosedural, pengalaman pengembang dengan Ant adalah dalam pengkodean bahasa prosedural yang ditulis dalam XML.

Bandingkan contoh Sem sebelumnya dengan contoh Maven. Di Maven, untuk membuat file JAR dari beberapa sumber Java, yang perlu Anda lakukan adalah membuat pom.xml sederhana, tempatkan kode sumber Anda di $ {basedir} / src / main / java dan kemudian jalankan mvn install dari baris perintah . Contohnya Maven pom.xml yang mencapai hasil yang sama.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
</project>

Itu saja yang Anda butuhkan di pom.xml Anda. Menjalankan mvn instal dari baris perintah akan memproses sumber daya, mengkompilasi sumber, menjalankan pengujian unit, membuat JAR, dan menginstal JAR dalam repositori lokal untuk digunakan kembali dalam proyek lain. Tanpa modifikasi, Anda dapat menjalankan situs mvn dan kemudian menemukan file index.html di target / situs yang berisi tautan ke JavaDoc dan beberapa laporan tentang kode sumber Anda.

Harus diakui, ini adalah contoh proyek paling sederhana yang mungkin. Sebuah proyek yang hanya berisi kode sumber dan yang menghasilkan JAR. Sebuah proyek yang mengikuti konvensi Maven dan tidak memerlukan dependensi atau penyesuaian. Jika kami ingin mulai menyesuaikan perilaku, pom.xml kami akan bertambah besar, dan dalam sebagian besar proyek Anda dapat melihat koleksi POM Maven yang sangat kompleks yang berisi banyak penyesuaian plugin dan deklarasi dependensi. Tetapi, bahkan ketika file POM proyek Anda menjadi lebih besar, mereka menyimpan jenis informasi yang sama sekali berbeda dari file build proyek berukuran sama menggunakan Ant. POM Maven berisi deklarasi: "Ini adalah proyek JAR", dan "Kode sumber ada di src / main / java". Ant build file berisi instruksi eksplisit: "Ini proyek", "src/main/java"," Jalankan javacmelawan direktori ini "," Masukkan hasilnyatarget/classses "," Buat JAR dari .... ", dll. Di mana Sem harus eksplisit tentang prosesnya, ada sesuatu" bawaan "untuk Maven yang hanya tahu di mana kode sumber itu dan bagaimana seharusnya diproses.

Perbandingan Tingkat Tinggi

Perbedaan antara Ant dan Maven dalam contoh ini? Semut...

  • tidak memiliki konvensi formal seperti struktur direktori proyek umum, Anda harus memberi tahu Ant di mana tepatnya untuk menemukan sumber dan di mana harus meletakkan hasilnya. Konvensi informal telah muncul dari waktu ke waktu, tetapi belum dikodifikasi ke dalam produk.
  • bersifat prosedural, Anda harus memberi tahu Ant apa yang harus dilakukan dan kapan melakukannya. Anda harus mengatakannya untuk dikompilasi, lalu salin, lalu kompres.
  • tidak memiliki siklus hidup, Anda harus menentukan sasaran dan ketergantungan tujuan. Anda harus melampirkan urutan tugas ke setiap sasaran secara manual.

Di mana Maven ...

  • memiliki konvensi, sudah tahu di mana kode sumber Anda karena Anda mengikuti konvensi. Itu menempatkan bytecode di target / kelas, dan menghasilkan file JAR di target.
  • bersifat deklaratif. Yang harus Anda lakukan adalah membuat file pom.xml dan meletakkan sumber Anda di direktori default. Maven mengurus sisanya.
  • memiliki siklus hidup, yang Anda panggil ketika Anda dieksekusi mvn install. Perintah ini menyuruh Maven untuk melakukan serangkaian langkah-langkah urutan hingga mencapai siklus hidup. Sebagai efek samping dari perjalanan ini melalui siklus hidup, Maven mengeksekusi sejumlah tujuan plugin default yang melakukan hal-hal seperti mengkompilasi dan membuat JAR.

Bagaimana dengan Ivy?

Benar, jadi seseorang seperti Steve Loughran akan membaca perbandingan itu dan menyebutnya busuk. Dia akan berbicara tentang bagaimana jawabannya benar-benar mengabaikan sesuatu yang disebut Ivy dan fakta bahwa Ant dapat menggunakan kembali logika dalam rilis terbaru dari Ant. Ini benar. Jika Anda memiliki banyak orang pintar yang menggunakan Ant + antlibs + Ivy, Anda akan mendapatkan build yang dirancang dengan baik. Meskipun, saya sangat yakin bahwa Maven masuk akal, saya dengan senang hati menggunakan Ant + Ivy dengan tim proyek yang memiliki insinyur bangunan yang sangat tajam. Yang sedang berkata, saya pikir Anda akhirnya akan kehilangan sejumlah plugin berharga seperti plugin Jetty dan bahwa Anda akhirnya akan melakukan banyak pekerjaan yang tidak perlu Anda lakukan dari waktu ke waktu.

Lebih Penting daripada Maven vs. Semut

  1. Apakah Anda menggunakan Manajer Repositori untuk melacak artefak perangkat lunak. Saya sarankan mengunduh Nexus . Anda dapat menggunakan Nexus untuk membuat repositori jarak jauh dan untuk menyediakan tempat bagi tim Anda untuk menggunakan artefak internal.
  2. Anda memiliki modularisasi komponen perangkat lunak yang sesuai. Satu komponen monolitik besar jarang bersisik dari waktu ke waktu. Saat proyek Anda berkembang, Anda pasti ingin memiliki konsep modul dan sub-modul. Maven cocok untuk pendekatan ini dengan sangat baik.
  3. Anda mengadopsi beberapa konvensi untuk bangunan Anda. Bahkan jika Anda menggunakan Semut, Anda harus berusaha untuk mengadopsi beberapa bentuk konvensi yang konsisten dengan proyek lain. Ketika sebuah proyek menggunakan Maven, itu berarti bahwa siapa pun yang akrab dengan Maven dapat mengambil build dan mulai menjalankannya tanpa harus mengutak-atik konfigurasi hanya untuk mencari cara untuk mendapatkan hal untuk dikompilasi.

1
Tautan rusak lagi.
Thunderforge

1
Saya menggunakan Nebeans dan Ant bekerja secara default tanpa penyetelan (konvensi Netbeans?). Saat ini mencoba Maven dan menemukannya lebih panjang saat membangun pertama dan terus-menerus menggunakan koneksi internet. Membangun offline mungkin tidak mungkin. Ini tidak nyaman.
Zon

113

Maven adalah Kerangka, Ant adalah Toolbox

Maven adalah mobil jalan pra-dibangun, sedangkan Ant adalah seperangkat bagian mobil. Dengan Semut Anda harus membuat mobil sendiri, tetapi setidaknya jika Anda perlu mengemudi di luar jalan, Anda dapat membangun jenis mobil yang tepat.

Dengan kata lain, Maven adalah kerangka kerja sedangkan Ant adalah kotak peralatan. Jika Anda puas bekerja dalam batasan kerangka maka Maven akan baik-baik saja. Masalahnya bagi saya adalah saya terus menabrak batas kerangka kerja dan itu tidak akan membiarkan saya keluar.

XML Verbosity

tobrien adalah pria yang tahu banyak tentang Maven dan saya pikir dia memberikan perbandingan yang sangat baik, jujur ​​dari kedua produk. Dia membandingkan pom.xml Maven sederhana dengan file build Ant sederhana dan dia menyebutkan bagaimana proyek Maven bisa menjadi lebih kompleks. Saya pikir patut melihat perbandingan beberapa file yang lebih mungkin Anda lihat dalam proyek dunia nyata yang sederhana. File-file di bawah ini mewakili modul tunggal dalam membangun multi-modul.

Pertama, file Maven:

<project 
    xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-4_0_0.xsd">

    <parent>
        <groupId>com.mycompany</groupId>
        <artifactId>app-parent</artifactId>
        <version>1.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>persist</artifactId>
    <name>Persistence Layer</name>

    <dependencies>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>common</artifactId>
            <scope>compile</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>domain</artifactId>
            <scope>provided</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>${hibernate.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>${commons-lang.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>${spring.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>2.2.3</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>${testng.version}</version>
            <scope>test</scope>
            <classifier>jdk15</classifier>
        </dependency>

        <dependency>
            <groupId>commons-dbcp</groupId>
            <artifactId>commons-dbcp</artifactId>
            <version>${commons-dbcp.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>com.oracle</groupId>
            <artifactId>ojdbc</artifactId>
            <version>${oracle-jdbc.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>${easymock.version}</version>
            <scope>test</scope>
        </dependency>

    </dependencies>

</project>

Dan file Ant yang setara:

<project name="persist" >

    <import file="../build/common-build.xml" />


    <path id="compile.classpath.main">
        <pathelement location="${common.jar}" />
        <pathelement location="${domain.jar}" />
        <pathelement location="${hibernate.jar}" />
        <pathelement location="${commons-lang.jar}" />
        <pathelement location="${spring.jar}" />
    </path>


    <path id="compile.classpath.test">
        <pathelement location="${classes.dir.main}" />
        <pathelement location="${testng.jar}" />
        <pathelement location="${dbunit.jar}" />
        <pathelement location="${easymock.jar}" />
        <pathelement location="${commons-dbcp.jar}" />
        <pathelement location="${oracle-jdbc.jar}" />
        <path refid="compile.classpath.main" />
    </path>


    <path id="runtime.classpath.test">
        <pathelement location="${classes.dir.test}" />
        <path refid="compile.classpath.test" />
    </path>


</project>

tobrien menggunakan contohnya untuk menunjukkan bahwa Maven memiliki konvensi bawaan tetapi itu tidak berarti bahwa Anda akhirnya lebih sedikit menulis XML. Saya telah menemukan yang sebaliknya benar. Pom.xml adalah 3 kali lebih lama dari build.xml dan itu tanpa menyimpang dari konvensi. Bahkan, contoh Maven saya ditampilkan tanpa 54 baris tambahan yang diperlukan untuk mengkonfigurasi plugin. Pom.xml itu untuk proyek sederhana. XML benar-benar mulai tumbuh secara signifikan ketika Anda mulai menambahkan persyaratan tambahan, yang tidak biasa untuk banyak proyek.

Tetapi Anda harus memberi tahu Ant apa yang harus dilakukan

Contoh semut saya di atas tidak lengkap tentunya. Kita masih harus mendefinisikan target yang digunakan untuk membersihkan, mengkompilasi, menguji dll. Ini didefinisikan dalam file build umum yang diimpor oleh semua modul dalam proyek multi-modul. Yang mengarahkan saya ke titik tentang bagaimana semua hal ini harus ditulis secara eksplisit dalam Ant sedangkan itu deklaratif dalam Maven.

Memang benar, ini akan menghemat waktu saya jika saya tidak harus secara eksplisit menulis target Ant ini. Tapi berapa lama? File build umum yang saya gunakan sekarang adalah yang saya tulis 5 tahun yang lalu dengan sedikit perbaikan sejak saat itu. Setelah 2 tahun bereksperimen dengan Maven, saya mengeluarkan file lama semut dari lemari, membersihkannya dan mengembalikannya. Bagi saya, biaya karena harus secara eksplisit memberi tahu Ant apa yang harus dilakukan telah bertambah hingga kurang dari seminggu selama periode 5 tahun.

Kompleksitas

Perbedaan besar berikutnya yang ingin saya sebutkan adalah kompleksitas dan efek dunia nyata yang dimilikinya. Maven dibangun dengan tujuan mengurangi beban kerja pengembang yang ditugaskan untuk membuat dan mengelola proses pembangunan. Untuk melakukan ini harus kompleks. Sayangnya kompleksitas itu cenderung meniadakan tujuan yang diinginkan.

Jika dibandingkan dengan Ant, build guy pada proyek Maven akan menghabiskan lebih banyak waktu:

  • Membaca dokumentasi: Ada lebih banyak dokumentasi tentang Maven, karena ada begitu banyak lagi yang perlu Anda pelajari.
  • Mendidik anggota tim: Mereka merasa lebih mudah untuk bertanya kepada seseorang yang tahu daripada mencoba menemukan jawaban sendiri.
  • Memecahkan masalah build: Maven kurang dapat diandalkan dibandingkan Ant, terutama plugin non-inti. Juga, build Maven tidak dapat diulang. Jika Anda bergantung pada versi plugin SNAPSHOT, yang sangat mungkin, bangunan Anda dapat rusak tanpa Anda mengubah apa pun.
  • Menulis plugin Maven: Plugin biasanya ditulis dengan tugas tertentu, misalnya membuat bundel webstart, yang membuatnya lebih sulit untuk menggunakannya kembali untuk tugas lain atau menggabungkannya untuk mencapai tujuan. Jadi, Anda mungkin harus menulis salah satu dari Anda sendiri untuk mencari celah di set plugin yang ada.

Sebaliknya:

  • Dokumentasi semut ringkas, komprehensif, dan semuanya berada di satu tempat.
  • Semut itu sederhana. Pengembang baru yang mencoba mempelajari Sem hanya perlu memahami beberapa konsep sederhana (target, tugas, dependensi, properti) untuk dapat mengetahui sisa dari apa yang perlu mereka ketahui.
  • Semut bisa diandalkan. Belum ada banyak sekali rilis Ant selama beberapa tahun terakhir karena sudah berfungsi.
  • Build semut dapat diulang karena umumnya dibuat tanpa dependensi eksternal, seperti repositori online, plugin pihak ketiga eksperimental, dll.
  • Semut komprehensif. Karena ini adalah kotak alat, Anda dapat menggabungkan alat untuk melakukan hampir semua tugas yang Anda inginkan. Jika Anda perlu menulis tugas kustom Anda sendiri, ini sangat mudah dilakukan.

Keakraban

Perbedaan lainnya adalah keakraban. Pengembang baru selalu membutuhkan waktu untuk mempercepat. Keakraban dengan produk yang ada membantu dalam hal itu dan pendukung Maven dengan tepat mengklaim bahwa ini adalah manfaat Maven. Tentu saja, fleksibilitas Ant berarti Anda dapat membuat konvensi apa pun yang Anda suka. Jadi konvensi yang saya gunakan adalah meletakkan file sumber saya di nama direktori src / main / java. Kelas kompilasi saya masuk ke direktori bernama target / kelas. Kedengarannya tidak asing.

Saya suka struktur direktori yang digunakan oleh Maven. Saya pikir itu masuk akal. Juga siklus hidup mereka. Jadi saya menggunakan konvensi yang sama di build Ant saya. Bukan hanya karena itu masuk akal tetapi karena itu akan akrab bagi siapa saja yang telah menggunakan Maven sebelumnya.


7
Saya sangat suka bagaimana Anda "Mencuri" ide-ide dari Maven dan menerapkannya pada semut Anda untuk mengikuti konvensi umum dan membuat transisi lebih mudah bagi orang lain.
Igor Čordaš

Untuk menghindari mengasapi pom.xml, saya menghasilkan sebagian besar dari mereka melalui XSLT.
Demi

21

Semut terutama merupakan alat bangun.

Maven adalah alat manajemen proyek dan dependensi (yang tentu saja membangun proyek Anda juga).

Ant + Ivy adalah kombinasi yang cukup bagus jika Anda ingin menghindari Maven.


Ini. Perbandingan antara Ant + Ivy dan Maven2 di sini: ant.apache.org/ivy/m2comparison.html
Esko

Mengapa Anda ingin menghindari Maven? Maven, menurut pengalaman saya, adalah satu dari sedikit bagian dari pengembangan java yang menyenangkan.
Benson

4
@Benson: Ini masalah kontroversial. Jika itu adalah peluru perak maka semua orang akan menggunakannya.
cherouvim

18

Sekadar daftar beberapa perbedaan lagi:

  • Semut tidak memiliki konvensi formal. Anda harus memberi tahu Ant secara tepat di mana menemukan sumbernya, di mana harus meletakkan output, dll.
  • Semut bersifat prosedural. Anda harus memberi tahu Ant apa yang harus dilakukan; katakan untuk kompilasi, salin, lalu kompres, dll.
  • Semut tidak memiliki siklus hidup.
  • Maven menggunakan konvensi. Ia tahu di mana kode sumber Anda secara otomatis, selama Anda mengikuti konvensi ini. Anda tidak perlu memberi tahu Maven di mana itu.
  • Maven bersifat deklaratif; Yang harus Anda lakukan adalah membuat file pom.xml dan meletakkan sumber Anda di direktori default. Maven akan mengurus sisanya.
  • Maven memiliki siklus hidup. Anda cukup memanggil mvn install dan serangkaian langkah-langkah urutan dieksekusi.
  • Maven memiliki kecerdasan tentang tugas-tugas proyek umum. Untuk menjalankan tes, jalankan uji mvn , selama file berada di lokasi default. Di Ant, pertama-tama Anda harus JUnit JAR file, kemudian buat classpath yang mencakup JUnit JAR, kemudian beri tahu Ant di mana ia harus mencari kode sumber tes, menulis tujuan yang mengkompilasi sumber tes dan akhirnya menjalankan unit test dengan JUnit.

Memperbarui:

Ini datang dari Maven: Panduan Definitif . Maaf, saya benar-benar lupa mengutipnya.


Apakah itu pembaruan permainan kata?
vakio

1
@vakio - Saya akan menebak maksud Anda karena saya menggunakan "situs" alih-alih "mengutip"? Itu benar-benar ejaan yang buruk di pihak saya dan saya memperbaikinya
Ascalonian

17

Maven atau Semut? adalah pertanyaan yang sangat mirip dengan yang ini, yang seharusnya membantu Anda menjawab pertanyaan Anda.

Apa itu Maven? di situs resmi.

sunting: Untuk proyek baru / greenfield, saya sarankan menggunakan Maven: "convention over configuration" akan menghemat waktu yang cukup untuk menulis dan mengatur skrip build dan deployment. Saat Anda menggunakan semut, skrip build cenderung bertambah panjang dalam waktu dan kompleksitas. Untuk proyek-proyek yang ada, mungkin sulit untuk mengubah konfigurasi / tata letak mereka ke dalam sistem Maven.


Maven akan menghemat waktu Anda di awal proyek Anda, tetapi seiring waktu, jika Anda memiliki sesuatu selain proyek yang sangat sederhana, skrip Maven akan menjadi jauh lebih rumit daripada yang setara dengan Semut. Misalnya, lihat plugin Maven Assembly.
Kevin Stembridge

Saya berpendapat bahwa menyelesaikan apa yang dilakukan plugin Majelis jauh lebih mudah dilakukan dalam format Maven (di mana Anda meletakkan model perakitan dalam format xml) daripada melakukan semua langkah manual di Ant, tetapi YMMV
matt b

Hai Matt, kurva belajar untuk plugin perakitan jauh lebih curam dari itu untuk tugas Ant atau zip. Format deskriptor panjangnya sekitar 150 baris dan berisi sejumlah opsi konfigurasi non-intuitif. Selain itu, itu tidak berhasil! Pada titik saya menyerah pada plugin Majelis, pemfilteran pada unpack tidak berfungsi dan tidak juga opsi mode file dan tidak bisa memperbaikicrlf. Tidak yakin apa yang Anda maksud dengan "semua langkah manual di Ant". Saya menghabiskan sekitar 5 menit untuk membuat Semut melakukan apa yang tidak bisa saya lakukan dengan plugin perakitan dalam hitungan jam.
Kevin Stembridge

3
Tautan pertama sekarang mati: /
Matt Clark

15

Maven bertindak sebagai alat manajemen dependensi - ini dapat digunakan untuk mengambil stoples dari repositori pusat atau dari repositori yang Anda atur - dan sebagai alat pembangun deklaratif. Perbedaan antara alat bantu pembuatan "deklaratif" dan yang lebih tradisional seperti semut atau buatan adalah Anda mengonfigurasi apa yang harus dilakukan, bukan bagaimana melakukannya. Misalnya, Anda dapat mengatakan dalam skrip pakar bahwa suatu proyek harus dikemas sebagai file PERANG, dan pakar tahu cara mengatasinya.

Maven bergantung pada konvensi tentang bagaimana direktori proyek disusun untuk mencapai "deklaratifitasnya". Sebagai contoh, ia memiliki konvensi tentang di mana menempatkan kode utama Anda, di mana menempatkan web.xml Anda, pengujian unit Anda, dan sebagainya, tetapi juga memberikan kemampuan untuk mengubahnya jika Anda perlu.

Anda juga harus ingat bahwa ada plugin untuk menjalankan perintah semut dari dalam maven:

http://maven.apache.org/plugins/maven-ant-plugin/

Juga, arketipe maven membuat memulai dengan proyek sangat cepat. Sebagai contoh, ada pola dasar Wicket, yang menyediakan perintah pakar yang Anda jalankan untuk mendapatkan keseluruhan, proyek-proyek hello world-type yang siap dijalankan.

https://wicket.apache.org/start/quickstart.html


11

Saya dapat mengambil seseorang yang belum pernah melihat Ant - nya build.xml ini ditulis dengan cukup baik - dan mereka dapat memahami apa yang sedang terjadi. Saya dapat mengambil orang yang sama dan menunjukkan kepada mereka POM Maven dan mereka tidak akan tahu apa yang sedang terjadi.

Dalam organisasi rekayasa yang besar, orang menulis tentang file Ant menjadi besar dan tidak dapat dikelola. Saya sudah menulis jenis-jenis itu dan membersihkan skrip Ant. Ini benar-benar memahami apa yang perlu Anda lakukan ke depan dan merancang satu set template yang dapat merespons perubahan dan skala selama periode 3+ tahun.

Kecuali jika Anda memiliki proyek sederhana, mempelajari konvensi Maven dan cara Maven tentang menyelesaikan sesuatu adalah pekerjaan yang cukup berat.

Pada akhirnya, Anda tidak dapat mempertimbangkan memulai proyek dengan Ant atau Maven sebagai faktor: ini benar-benar total biaya kepemilikan. Apa yang diperlukan organisasi untuk mempertahankan dan memperluas sistem pembangunannya selama beberapa tahun adalah salah satu faktor utama yang harus dipertimbangkan.

Aspek yang paling penting dari sistem build adalah manajemen ketergantungan dan fleksibilitas dalam mengekspresikan resep build. Itu harus agak intuitif ketika dilakukan dengan baik.


6

Saya akan mengatakan itu tergantung pada ukuran proyek Anda ... Secara pribadi, saya akan menggunakan Maven untuk proyek-proyek sederhana yang memerlukan kompilasi, pengemasan, dan penyebaran yang mudah. Segera setelah Anda perlu melakukan beberapa hal yang lebih rumit (banyak dependensi, membuat file pemetaan ...), saya akan beralih ke Ant ...


Saya tidak setuju. Saya setuju bahwa ada baiknya menggunakan maven untuk proyek-proyek sederhana, tetapi saya berpendapat bahwa dengan semakin rumitnya manfaat Anda dari menggunakan maven akan meningkat dengan urutan besarnya.
Benson

Saya juga tidak setuju, Maven benar-benar mulai bekerja dengan baik ketika Anda memiliki sistem yang lebih kompleks dengan banyak modul yang saling terkait. Jika Anda perlu menulis tes fungsional, menjalankan laporan, dan menggunakan artefak ke manajer repositori, mengapa Anda melakukan semua itu sendiri dengan Ant?
Tim O'Brien

Maven baik-baik saja untuk proyek sederhana, tetapi saya punya mimpi buruk saat mencoba melakukan hal-hal yang seharusnya sederhana dalam proyek yang lebih kompleks. Misalnya membuat paket yang dapat didistribusikan, mengaburkan kode, membuat bundel webstart, mengkonfigurasi profil. @Benson, ketika proyek Anda menjadi lebih kompleks, Maven menjadi sebuah bola dan rantai. Kekuatan dan fleksibilitas Ant akan memberi Anda manfaat produktivitas yang lebih besar daripada Maven. @tobrien, Ant berfungsi dengan baik untuk proyek multi-modul, menulis tes fungsional, dll. Mengkonfigurasi plugin pelaporan non-standar di Maven biasanya lebih bertele-tele daripada setara Ant.
Kevin Stembridge

Saya baru saja mulai menambahkan pakar ke proyek yang ada dan saya menemukan bahwa semuanya tidak berfungsi seperti yang diharapkan. Situs web ini dibangun dalam php dan digunakan menggunakan skrip. Hal-hal ini tidak berfungsi dengan lancar di Maven, Anda harus membuat hal-hal yang sangat aneh untuk membuatnya bekerja.
Raul Luna

4

Maven juga memiliki repositori besar untuk proyek open source yang umum digunakan. Selama proses pembuatan, Maven dapat mengunduh dependensi ini untuk Anda (dan juga dependensi dependensi Anda :)) untuk membuat bagian membangun proyek ini sedikit lebih mudah dikelola.


2
+1, setelah melihat apa yang diperlukan untuk menjaga Repositori Central Maven tetap berjalan, saya harus berpadu dan menyarankan agar semua orang yang menggunakan sesuatu seperti Maven dan Ivy harus mempertimbangkan untuk menginstal manajer repositori. Tidak masalah yang mana, tapi saya sebagian dengan Nexus nexus.sonatype.org .
Tim O'Brien
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.