Maven to Framework, Ant to Toolbox
Maven to fabrycznie zbudowany samochód drogowy, a Ant to zestaw części samochodowych. Z Antem musisz zbudować własny samochód, ale przynajmniej jeśli chcesz jeździć w terenie, możesz zbudować odpowiedni rodzaj samochodu.
Innymi słowy, Maven to framework, a Ant to zestaw narzędzi. Jeśli jesteś zadowolony z pracy w ramach frameworka, Maven będzie w porządku. Problemem było to, że ciągle wpadałem na granice frameworka i nie wypuściło mnie to.
Szczegółowość XML
tobrien jest facetem, który dużo wie o Maven i myślę, że zapewnił bardzo dobre, uczciwe porównanie tych dwóch produktów. Porównał prosty Maven pom.xml z prostym plikiem kompilacji Anta i wspomniał o tym, jak projekty Maven mogą stać się bardziej złożone. Myślę, że warto spojrzeć na porównanie kilku plików, które są bardziej prawdopodobne w prostym projekcie z prawdziwego świata. Poniższe pliki reprezentują pojedynczy moduł w wersji wielomodułowej.
Po pierwsze, plik 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>
I równoważny plik Ant:
<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 wykorzystał swój przykład, aby pokazać, że Maven ma wbudowane konwencje, ale to niekoniecznie oznacza, że w końcu piszesz mniej XML. Uważam, że jest odwrotnie. Plik pom.xml jest 3 razy dłuższy niż plik build.xml i to bez odchodzenia od konwencji. W rzeczywistości mój przykład Maven jest pokazany bez dodatkowych 54 linii wymaganych do skonfigurowania wtyczek. Ten plik pom.xml jest przeznaczony do prostego projektu. XML naprawdę zaczyna rosnąć, gdy zaczynasz dodawać dodatkowe wymagania, co nie jest niczym niezwykłym w wielu projektach.
Ale musisz powiedzieć Antowi, co ma robić
Powyższy przykład mrówki nie jest oczywiście kompletny. Nadal musimy zdefiniować cele używane do czyszczenia, kompilacji, testowania itp. Są one zdefiniowane we wspólnym pliku kompilacji, który jest importowany przez wszystkie moduły w projekcie wielomodułowym. Co prowadzi mnie do tego, że wszystkie te rzeczy muszą być wyraźnie napisane w Ant, podczas gdy w Maven jest deklaratywne.
To prawda, że zaoszczędziłbym czas, gdybym nie musiał wyraźnie pisać tych celów Ant. Ale ile czasu? Wspólny plik kompilacji, którego teraz używam, to taki, który napisałem 5 lat temu, od tego czasu tylko nieznacznie dopracowując. Po 2-letnim eksperymencie z Mavenem wyciągnąłem z szafy stary plik kompilacji Anta, odkurzyłem go i przywróciłem do pracy. Dla mnie koszt konieczności wyraźnego powiedzenia Antowi, co należy zrobić, wyniósł mniej niż tydzień w ciągu 5 lat.
Złożoność
Kolejną znaczącą różnicą, o której chciałbym wspomnieć, jest złożoność i rzeczywisty efekt, jaki ma. Maven został zbudowany z myślą o zmniejszeniu obciążenia programistów odpowiedzialnych za tworzenie i zarządzanie procesami kompilacji. Aby to zrobić, musi być złożony. Niestety ta złożoność ma tendencję do negowania zamierzonego celu.
W porównaniu z Antem facet z kompilacji w projekcie Maven poświęci więcej czasu:
- Czytanie dokumentacji: Dokumentacja Maven zawiera znacznie więcej dokumentacji, ponieważ musisz nauczyć się o wiele więcej.
- Edukowanie członków zespołu: Łatwiej jest zapytać kogoś, kto wie, niż samemu znaleźć odpowiedzi.
- Rozwiązywanie problemów z kompilacją: Maven jest mniej niezawodny niż Ant, szczególnie wtyczki inne niż Core. Ponadto kompilacje Maven nie są powtarzalne. Jeśli zależy Ci na wersji wtyczki SNAPSHOT, co jest bardzo prawdopodobne, twoja kompilacja może się zepsuć bez zmiany czegokolwiek.
- Pisanie wtyczek Maven: Wtyczki są zwykle pisane z myślą o określonym zadaniu, np. Tworzą pakiet webstart, co utrudnia ponowne użycie ich do innych zadań lub połączenie ich w celu osiągnięcia celu. Być może będziesz musiał napisać własną, aby obejść luki w istniejącym zestawie wtyczek.
W przeciwieństwie:
- Dokumentacja mrówek jest zwięzła, wyczerpująca i wszystko w jednym miejscu.
- Mrówka jest prosta. Nowy programista próbujący nauczyć się Anta musi zrozumieć tylko kilka prostych pojęć (cele, zadania, zależności, właściwości), aby móc zrozumieć resztę tego, co powinien wiedzieć.
- Mrówka jest niezawodna. W ciągu ostatnich kilku lat nie było bardzo wielu wydań Anta, ponieważ już działa.
- Kompilacje mrówek są powtarzalne, ponieważ generalnie są tworzone bez żadnych zewnętrznych zależności, takich jak repozytoria online, eksperymentalne wtyczki innych firm itp.
- Mrówka jest kompleksowa. Ponieważ jest to zestaw narzędzi, możesz łączyć narzędzia, aby wykonać prawie każde zadanie, jakie chcesz. Jeśli kiedykolwiek chcesz napisać własne niestandardowe zadanie, jest to bardzo proste.
Znajomość
Kolejną różnicą jest znajomość. Nowi programiści zawsze potrzebują czasu, aby przyśpieszyć. Znajomość istniejących produktów pomaga w tym względzie, a zwolennicy Maven słusznie twierdzą, że jest to korzyść Maven. Oczywiście elastyczność Anta oznacza, że możesz tworzyć dowolne konwencje. Więc konwencja, której używam, polega na umieszczeniu moich plików źródłowych w nazwie katalogu src / main / java. Moje skompilowane klasy przechodzą do katalogu o nazwie target / class. Brzmi znajomo, prawda?
Podoba mi się struktura katalogów używana przez Maven. Myślę, że to ma sens. Również ich cykl życia. Dlatego używam tych samych konwencji w moich kompilacjach Ant. Nie tylko dlatego, że ma to sens, ale dlatego, że będzie znany każdemu, kto wcześniej korzystał z Maven.