Perbedaan antara Semut dan Maven [ditutup]

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.

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.

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.

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.

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.

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

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.

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

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.