Tại sao nên sử dụng Gradle thay vì Ant hay Maven? [đóng cửa]

Một công cụ xây dựng khác nhắm vào Java thực sự mang lại cho tôi điều gì?

Nếu bạn sử dụng Gradle trên một công cụ khác, tại sao?

Bản thân tôi không sử dụng Gradle trong sự tức giận (chỉ là một dự án đồ chơi) [tác giả có nghĩa là họ đã sử dụng Gradle cho một dự án đồ chơi cho đến nay, không phải Gradle là một dự án đồ chơi - xem bình luận] , nhưng tôi nói rằng những lý do người ta sẽ cân nhắc sử dụng nó là vì sự thất vọng của Ant và Maven.

Theo kinh nghiệm của tôi, Ant thường chỉ viết (vâng, tôi biết có thể viết mô-đun đẹp, thanh lịch , nhưng thực tế là hầu hết mọi người không làm như vậy). Đối với bất kỳ dự án không tầm thường nào, nó trở nên khó hiểu và rất cẩn thận để đảm bảo rằng các bản dựng phức tạp thực sự di động. Bản chất bắt buộc của nó có thể dẫn đến việc sao chép cấu hình giữa các bản dựng (mặc dù các macro có thể giúp ở đây).

Maven có cách tiếp cận ngược lại và mong bạn tích hợp hoàn toàn với vòng đời Maven. Người dùng Ant có kinh nghiệm nhận thấy điều này đặc biệt chói tai khi Maven loại bỏ nhiều quyền tự do mà bạn có trong Ant. Ví dụ, có một blog Sonatype liệt kê nhiều lời chỉ trích của Maven và phản hồi của họ.

Cơ chế plugin Maven cho phép cấu hình bản dựng rất mạnh và mô hình thừa kế có nghĩa là bạn có thể xác định một nhóm nhỏ POM cha mẹ đóng gói cấu hình bản dựng của bạn cho toàn bộ doanh nghiệp và các dự án riêng lẻ có thể kế thừa các cấu hình đó, khiến chúng nhẹ. Cấu hình Maven rất dài dòng (mặc dù Maven 3 hứa sẽ giải quyết vấn đề này) và nếu bạn muốn làm bất cứ điều gì "không phải theo cách của Maven", bạn phải viết một plugin hoặc sử dụng tích hợp Ant hacky. Lưu ý tôi tình cờ thích viết các plugin Maven nhưng đánh giá cao rằng nhiều người sẽ phản đối những nỗ lực liên quan.

Gradle hứa hẹn sẽ đạt được điểm ngọt ngào giữa Ant và Maven. Nó sử dụng phương pháp của Ivy để giải quyết phụ thuộc. Nó cho phép quy ước về cấu hình nhưng cũng bao gồm các nhiệm vụ Ant là công dân hạng nhất. Nó cũng khôn ngoan cho phép bạn sử dụng kho lưu trữ Maven / Ivy hiện có.

Vì vậy, nếu bạn đã đánh và bị mắc kẹt với bất kỳ điểm đau Ant / Maven nào, có lẽ đáng để thử Gradle, mặc dù theo tôi, nó vẫn được nhìn thấy nếu bạn không giao dịch những vấn đề đã biết cho những người chưa biết. Bằng chứng của bánh pudding là trong việc ăn mặc dù vậy tôi sẽ bảo lưu phán quyết cho đến khi sản phẩm trưởng thành hơn một chút và những người khác đã giải quyết bất kỳ kink nào (họ gọi đó là lý do chảy máu vì lý do). Mặc dù vậy, tôi vẫn sẽ sử dụng nó trong các dự án đồ chơi của mình, Thật tốt khi biết các tùy chọn.

Gradle có thể được sử dụng cho nhiều mục đích - đó là một con dao quân đội Thụy Sĩ tốt hơn nhiều so với Ant - nhưng nó đặc biệt tập trung vào các bản dựng đa dự án.

Trước hết, Gradle là một công cụ lập trình phụ thuộc, cũng có nghĩa là nó là một công cụ lập trình. Với Gradle, bạn có thể thực hiện bất kỳ tác vụ ngẫu nhiên nào trong thiết lập của mình và Gradle sẽ đảm bảo tất cả các phụ thuộc được khai báo được thực hiện đúng và kịp thời. Mã của bạn có thể được trải rộng trên nhiều thư mục theo bất kỳ loại bố cục nào (cây, phẳng, rải rác, ...).

Gradle có hai giai đoạn riêng biệt: đánh giá và thực hiện. Về cơ bản, trong quá trình đánh giá Gradle sẽ tìm kiếm và đánh giá các tập lệnh xây dựng trong các thư mục mà nó được cho là sẽ tìm. Trong quá trình thực thi, Gradle sẽ thực thi các tác vụ đã được tải trong quá trình đánh giá có tính đến các phụ thuộc của nhiệm vụ.

Ngoài các tính năng lập trình phụ thuộc này, Gradle còn thêm các tính năng phụ thuộc của dự án và JAR bằng cách tích hợp với Apache Ivy. Như bạn đã biết Ivy là một công cụ quản lý phụ thuộc mạnh mẽ hơn và ít gây tranh cãi hơn so với Maven.

Gradle phát hiện sự phụ thuộc giữa các dự án và giữa các dự án và JAR. Gradle hoạt động với kho lưu trữ Maven (tải xuống và tải lên) như iBiblio hoặc kho lưu trữ của riêng bạn nhưng cũng hỗ trợ và loại cơ sở hạ tầng kho lưu trữ khác mà bạn có thể có.

Trong các bản dựng đa dự án, Gradle vừa có thể thích nghi vừa thích nghi với cấu trúc và kiến ​​trúc của bản dựng. Bạn không phải điều chỉnh cấu trúc hoặc kiến ​​trúc của mình với công cụ xây dựng như yêu cầu với Maven.

Gradle cố gắng hết sức để không cản đường bạn, một nỗ lực mà Maven gần như không bao giờ thực hiện được. Công ước là tốt nhưng sự linh hoạt cũng vậy. Gradle cung cấp cho bạn nhiều tính năng hơn Maven nhưng quan trọng nhất là trong nhiều trường hợp, Gradle sẽ cung cấp cho bạn một con đường chuyển tiếp không đau đớn từ Maven.

Điều này có thể gây tranh cãi một chút, nhưng Gradle không che giấu sự thật rằng đó là một ngôn ngữ lập trình đầy đủ.

Ant + ant-contrib về cơ bản là một ngôn ngữ lập trình hoàn chỉnh mà không ai thực sự muốn lập trình.

Maven cố gắng thực hiện cách tiếp cận ngược lại là cố gắng hoàn toàn khai báo và buộc bạn phải viết và biên dịch một plugin nếu bạn cần logic. Nó cũng áp đặt một mô hình dự án hoàn toàn không linh hoạt. Gradle kết hợp tốt nhất của tất cả các công cụ này:

• Nó tuân theo cấu hình quá mức (ala Maven) nhưng chỉ trong phạm vi bạn muốn
• Nó cho phép bạn viết các tác vụ tùy chỉnh linh hoạt như trong Ant
• Nó cung cấp hỗ trợ dự án đa mô-đun vượt trội hơn cả Ant và Maven
• Nó có DSL giúp 80% mọi thứ trở nên dễ dàng và 20% mọi thứ có thể (không giống như các công cụ xây dựng khác giúp 80% dễ dàng, 10% có thể và 10% hiệu quả là không thể).

Gradle là công cụ xây dựng linh hoạt và cấu hình nhất mà tôi chưa sử dụng. Nó đòi hỏi một số tiền đầu tư trước để tìm hiểu DSL và các khái niệm như cấu hình nhưng nếu bạn cần một công cụ xây dựng JVM vô nghĩa và hoàn toàn có thể cấu hình được thì thật khó để đánh bại.

Gradle kết hợp độc đáo cả Ant và Maven, tận dụng tốt nhất từ ​​cả hai khung. Tính linh hoạt từ Ant và quy ước về cấu hình, quản lý phụ thuộc và plugin từ Maven.

Vì vậy, nếu bạn muốn có một bản dựng java tiêu chuẩn, như trong maven, nhưng tác vụ thử nghiệm phải thực hiện một số bước tùy chỉnh, nó có thể trông như dưới đây.

bản dựng.

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

Trên hết, nó sử dụng cú pháp Groovy mang lại sức mạnh biểu hiện nhiều hơn sau đó là xml của ant / maven.

Nó là một superset của Ant - bạn có thể sử dụng tất cả các tác vụ Ant trong lớp với cú pháp đẹp hơn, giống như Groovy, tức là.

ant.copy(file:'a.txt', toDir:"xyz")

hoặc là

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

Chúng tôi sử dụng Gradle và chọn nó trên Maven và Ant. Ant đã cho chúng tôi sự linh hoạt hoàn toàn và Ivy cho phép quản lý phụ thuộc tốt hơn Maven, nhưng không có sự hỗ trợ tuyệt vời nào cho các bản dựng đa dự án. Bạn cuối cùng đã làm rất nhiều mã hóa để hỗ trợ xây dựng nhiều dự án. Ngoài ra có một số quy ước xây dựng là tốt và làm cho các kịch bản xây dựng ngắn gọn hơn. Với Maven, việc xây dựng theo quy ước quá xa và việc tùy chỉnh quy trình xây dựng của bạn trở thành một hack. Ngoài ra, Maven thúc đẩy mọi dự án xuất bản một vật phẩm. Đôi khi bạn có một dự án được chia thành các tiểu dự án nhưng bạn muốn tất cả các tiểu dự án được xây dựng và phiên bản cùng nhau. Không thực sự một cái gì đó Maven được thiết kế cho.

Với Gradle, bạn có thể có sự linh hoạt của Ant và xây dựng theo quy ước của Maven. Ví dụ, việc mở rộng vòng đời xây dựng thông thường với nhiệm vụ của bạn là chuyện nhỏ. Và bạn không bị buộc phải sử dụng một quy ước nếu bạn không muốn. Groovy mã đẹp hơn nhiều so với XML. Trong Gradle, bạn có thể xác định các phụ thuộc giữa các dự án trên hệ thống tệp cục bộ mà không cần phải xuất bản các tạo phẩm cho từng kho lưu trữ. Cuối cùng, Gradle sử dụng Ivy, vì vậy nó có quản lý phụ thuộc tuyệt vời. Nhược điểm duy nhất đối với tôi cho đến nay là thiếu tích hợp Eclipse trưởng thành, nhưng các tùy chọn cho Maven không thực sự tốt hơn nhiều.

Đây không phải là câu trả lời của tôi , nhưng nó chắc chắn cộng hưởng với tôi. Đó là từ Radar công nghệ của Th ThinkWorks từ tháng 10 năm 2012 :

Hai điều đã gây ra sự mệt mỏi với các công cụ xây dựng dựa trên XML như Ant và Maven: quá nhiều dấu ngoặc nhọn giận dữ và sự thô cứng của các kiến ​​trúc trình cắm thêm. Mặc dù các vấn đề cú pháp có thể được xử lý thông qua việc tạo, các kiến ​​trúc trình cắm thêm đã hạn chế nghiêm trọng khả năng các công cụ xây dựng phát triển một cách duyên dáng khi các dự án trở nên phức tạp hơn. Chúng tôi đã cảm thấy rằng các trình cắm thêm là mức độ trừu tượng sai và thay vào đó thích các công cụ dựa trên ngôn ngữ như Gradle và Rake, vì chúng cung cấp các bản tóm tắt chi tiết hơn và linh hoạt hơn về lâu dài.

Gradle đưa niềm vui trở lại vào phần mềm xây dựng / lắp ráp. Tôi đã sử dụng kiến ​​để xây dựng phần mềm trong toàn bộ sự nghiệp của mình và tôi luôn coi phần "xây dựng" thực sự của công việc nhà phát triển là một điều ác cần thiết. Vài tháng trước, công ty chúng tôi đã mệt mỏi vì không sử dụng repo nhị phân (hay còn gọi là kiểm tra các lọ vào vcs) và tôi được giao nhiệm vụ điều tra việc này. Bắt đầu với cây thường xuân vì nó có thể được gắn trên đầu con kiến, không có nhiều may mắn khi các tác phẩm được xây dựng của tôi được xuất bản như tôi muốn. Tôi đã tìm kiếm maven và hack đi với xml, làm việc tuyệt vời cho một số lib người trợ giúp đơn giản nhưng tôi gặp phải vấn đề nghiêm trọng khi cố gắng gói các ứng dụng sẵn sàng để triển khai. Đã sử dụng khá nhiều thời gian để tìm kiếm các plugin và đọc diễn đàn và tải xuống hàng nghìn tỷ lọ hỗ trợ cho các plugin khác nhau mà tôi gặp khó khăn khi sử dụng.

Nhưng từ ngày một tâm trạng của tôi bắt đầu cải thiện. Tôi đã nhận được ở đâu đó. Mất hai giờ để di chuyển mô-đun kiến ​​đầu tiên của tôi và tệp xây dựng về cơ bản không có gì. Dễ dàng trang bị một màn hình. "Wow" lớn là: xây dựng các tập lệnh trong xml, thật là ngu ngốc? thực tế là việc khai báo một phụ thuộc mất MỘT hàng rất hấp dẫn đối với tôi -> bạn có thể dễ dàng thấy tất cả các phụ thuộc cho một dự án nhất định trên một trang. Từ đó trở đi tôi không ngừng nghỉ, cho mọi vấn đề tôi gặp phải cho đến nay đều có một giải pháp đơn giản và thanh lịch. Tôi nghĩ đây là những lý do:

• Groovy rất trực quan cho các nhà phát triển java
• tài liệu tuyệt vời đến tuyệt vời
• sự linh hoạt là vô tận

Bây giờ tôi dành nhiều ngày cố gắng nghĩ ra các tính năng mới để thêm vào quá trình xây dựng của chúng tôi. Làm thế nào là bệnh?

Nó cũng dễ dàng hơn nhiều để quản lý các bản dựng gốc. Ant và Maven chỉ có hiệu quả trên Java. Một số plugin tồn tại cho Maven cố gắng xử lý một số dự án gốc, nhưng chúng không thực hiện công việc hiệu quả. Nhiệm vụ Ant có thể được viết để biên dịch các dự án bản địa, nhưng chúng quá phức tạp và vụng về.

Chúng tôi làm Java với JNI và rất nhiều bit gốc khác. Gradle đơn giản hóa lộn xộn Ant của chúng tôi đáng kể. Khi chúng tôi bắt đầu giới thiệu quản lý phụ thuộc vào các dự án bản địa, nó rất lộn xộn. Chúng tôi đã có Maven để làm điều đó, nhưng mã Gradle tương đương là một phần rất nhỏ của những gì cần thiết ở Maven, và mọi người có thể đọc nó và hiểu nó mà không cần trở thành Maven gurus.

Tôi đồng ý một phần với Ed Staub. Gradle chắc chắn là mạnh hơn so với maven và cung cấp sự linh hoạt lâu dài hơn.

Sau khi thực hiện đánh giá để chuyển từ maven sang gradle, chúng tôi đã quyết định tự dính vào maven vì hai vấn đề chúng tôi gặp phải với gradle (tốc độ chậm hơn maven, proxy không hoạt động).