Maven là một Framework, Ant là một Toolbox
Maven là một chiếc xe đường được chế tạo sẵn, trong khi Ant là một bộ phụ tùng xe hơi. Với Ant bạn phải tự chế tạo chiếc xe của mình, nhưng ít nhất nếu bạn cần thực hiện bất kỳ việc lái xe địa hình nào, bạn có thể chế tạo đúng loại xe.
Nói cách khác, Maven là một khung trong khi Ant là một hộp công cụ. Nếu bạn hài lòng với việc làm việc trong giới hạn của khung thì Maven sẽ làm tốt. Vấn đề đối với tôi là tôi đã va vào giới hạn của khung và nó sẽ không cho phép tôi ra ngoài.
Độ dài của XML
tobrien là một chàng trai biết rất nhiều về Maven và tôi nghĩ anh ta đã cung cấp một so sánh rất trung thực, tốt đẹp về hai sản phẩm. Anh ta đã so sánh một tệp paven Maven đơn giản với tệp xây dựng Ant đơn giản và anh ta đã đề cập đến cách các dự án Maven có thể trở nên phức tạp hơn. Tôi nghĩ rằng đáng để xem qua so sánh một vài tệp mà bạn có thể thấy trong một dự án thực tế đơn giản. Các tệp bên dưới đại diện cho một mô-đun duy nhất trong bản dựng đa mô-đun.
Đầu tiên, tệp 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>
Và tệp Ant tương đương:
<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 đã sử dụng ví dụ của mình để chỉ ra rằng Maven có các quy ước tích hợp nhưng điều đó không nhất thiết có nghĩa là bạn kết thúc việc viết ít XML hơn. Tôi đã tìm thấy điều ngược lại là đúng. Pom.xml dài hơn 3 lần so với build.xml và điều đó không đi lạc khỏi các quy ước. Trong thực tế, ví dụ Maven của tôi được hiển thị mà không cần thêm 54 dòng được yêu cầu để định cấu hình bổ trợ. Pom.xml đó là một dự án đơn giản. XML thực sự bắt đầu tăng trưởng đáng kể khi bạn bắt đầu thêm các yêu cầu bổ sung, điều này không nằm ngoài dự đoán của nhiều dự án.
Nhưng bạn phải nói với Ant phải làm gì
Tất nhiên ví dụ Ant của tôi ở trên không hoàn thành. Chúng ta vẫn phải xác định các mục tiêu được sử dụng để dọn dẹp, biên dịch, kiểm tra, v.v. Những mục tiêu này được xác định trong một tệp xây dựng chung được nhập bởi tất cả các mô-đun trong dự án đa mô-đun. Điều này dẫn tôi đến điểm về cách tất cả những thứ này phải được viết rõ ràng bằng Ant trong khi nó được khai báo trong Maven.
Đó là sự thật, nó sẽ giúp tôi tiết kiệm thời gian nếu tôi không phải viết rõ ràng các mục tiêu Ant này. Nhưng bao nhiêu thời gian? Tệp xây dựng phổ biến tôi sử dụng bây giờ là tệp mà tôi đã viết 5 năm trước chỉ với các tinh chỉnh nhỏ kể từ đó. Sau 2 năm thử nghiệm với Maven, tôi đã rút tập tin Ant cũ ra khỏi tủ, lau sạch nó và đưa nó trở lại hoạt động. Đối với tôi, chi phí phải nói rõ ràng với Ant những việc cần làm đã tăng thêm chưa đầy một tuần trong khoảng thời gian 5 năm.
Phức tạp
Sự khác biệt lớn tiếp theo tôi muốn đề cập đến là sự phức tạp và hiệu ứng trong thế giới thực. Maven được xây dựng với mục đích giảm khối lượng công việc của các nhà phát triển được giao nhiệm vụ tạo và quản lý các quy trình xây dựng. Để làm điều này nó phải phức tạp. Thật không may rằng sự phức tạp có xu hướng phủ nhận mục tiêu dự định của họ.
Khi được so sánh với Ant, anh chàng xây dựng trong dự án Maven sẽ dành nhiều thời gian hơn:
- Đọc tài liệu: Có nhiều tài liệu hơn về Maven, bởi vì có rất nhiều thứ bạn cần phải học.
- Giáo dục các thành viên trong nhóm: Họ thấy dễ dàng hơn khi hỏi một người biết hơn là cố gắng tự tìm câu trả lời.
- Khắc phục sự cố bản dựng: Maven kém tin cậy hơn Ant, đặc biệt là các plugin không lõi. Ngoài ra, các bản dựng Maven không thể lặp lại. Nếu bạn phụ thuộc vào phiên bản SNAPSHOT của plugin, rất có thể, bản dựng của bạn có thể bị hỏng mà bạn không thay đổi gì.
- Viết các plugin Maven: Các plugin thường được viết với một nhiệm vụ cụ thể, ví dụ: tạo một gói webstart, điều này gây khó khăn hơn cho việc sử dụng lại chúng cho các nhiệm vụ khác hoặc kết hợp chúng để đạt được mục tiêu. Vì vậy, bạn có thể phải viết một trong những khoảng trống của riêng bạn để giải quyết các khoảng trống trong bộ plugin hiện có.
Ngược lại:
- Ant tài liệu ngắn gọn, toàn diện và tất cả ở một nơi.
- Kiến rất đơn giản. Một nhà phát triển mới cố gắng học Ant chỉ cần hiểu một vài khái niệm đơn giản (mục tiêu, nhiệm vụ, phụ thuộc, thuộc tính) để có thể tìm ra phần còn lại của những gì họ cần biết.
- Kiến là đáng tin cậy. Đã không có nhiều bản phát hành của Ant trong vài năm qua vì nó đã hoạt động.
- Các bản dựng Ant có thể lặp lại vì chúng thường được tạo mà không có bất kỳ phụ thuộc bên ngoài nào, chẳng hạn như kho lưu trữ trực tuyến, plugin của bên thứ ba thử nghiệm, v.v.
- Kiến là toàn diện. Vì là hộp công cụ, bạn có thể kết hợp các công cụ để thực hiện hầu hết mọi tác vụ bạn muốn. Nếu bạn cần viết tác vụ tùy chỉnh của riêng mình, việc này rất đơn giản.
Quen thuộc
Một sự khác biệt nữa là sự quen thuộc. Các nhà phát triển mới luôn đòi hỏi thời gian để đạt được tốc độ. Sự quen thuộc với các sản phẩm hiện có giúp ích trong vấn đề đó và những người ủng hộ Maven tuyên bố đúng rằng đây là lợi ích của Maven. Tất nhiên, tính linh hoạt của Ant có nghĩa là bạn có thể tạo bất kỳ quy ước nào bạn muốn. Vì vậy, quy ước tôi sử dụng là đặt các tệp nguồn của mình vào một tên thư mục src / main / java. Các lớp biên dịch của tôi đi vào một thư mục có tên đích / lớp. Nghe có vẻ không quen.
Tôi thích cấu trúc thư mục được sử dụng bởi Maven. Tôi nghĩ rằng nó có ý nghĩa. Ngoài ra vòng đời xây dựng của họ. Vì vậy, tôi sử dụng các quy ước tương tự trong các bản dựng Ant của tôi. Không chỉ vì nó có ý nghĩa mà bởi vì nó sẽ quen thuộc với bất kỳ ai đã sử dụng Maven trước đây.