so sánh sbt và Gradle [đã đóng]

Tôi đang đi sâu vào Scala và nhận thấy sbt. Tôi khá hài lòng với Gradle trong các dự án java / groovy và tôi biết có một plugin scala cho Gradle.

Điều gì có thể là lý do chính đáng để ủng hộ sbt hơn Gradle trong một dự án Scala?

Lưu ý rằng một điểm khác biệt chính giữa SBT và Gradle là quản lý phụ thuộc của nó :

• SBT : Ivy , với một bản sửa đổi có thể được cung cấp dưới dạng bản sửa đổi (1.5.2, chẳng hạn) hoặc mới nhất (hoặc động).
  Xem " Ivy Dependency "
  Điều đó có nghĩa là hỗ trợ cơ chế "-SNAPSHOT" có thể có vấn đề, mặc dù Mark Harrah đã nêu chi tiết trong chủ đề này :

Đúng là bộ nhớ cache có thể bị nhầm lẫn, nhưng không đúng là Ivy không hiểu cách giải quyết các ảnh chụp nhanh. Eugene giải thích điểm này trong một chủ đề khác, có lẽ trong danh sách quản trị viên. Có một vấn đề với tự động cập nhật của sbt đã được giải quyết trong 0.12.

Những gì Ivy không hỗ trợ, theo như tôi biết, là xuất bản ảnh chụp nhanh theo cách Maven làm. Tôi tin rằng tôi đã nói điều này ở nơi khác, nhưng nếu bất kỳ ai muốn cải thiện tình hình, ý kiến ​​của tôi là tốt nhất nên dành nỗ lực làm việc với nhóm Gradle để sử dụng lại mã quản lý phụ thuộc của họ.

• Gradle : Chủ đề này đề cập đến ( Peter Niederwieser ):

Xin cho bạn biết, các vấn đề với sự phụ thuộc vào ảnh chụp nhanh Ivy và Maven là một trong những lý do tại sao Gradle cuối cùng đã thay thế Ivy bằng mã quản lý phụ thuộc của riêng mình. Đó là một nhiệm vụ lớn, nhưng đã mang lại cho chúng tôi rất nhiều điều tốt đẹp.

Dòng tweet này đề cập rằng mọi tình huống có thể phát triển trong tương lai:

Trước đây Mark từng nói rằng anh ấy quan tâm đến việc sử dụng Gradle thay vì Ivy cho SBT.

(cả hai công cụ có thể học hỏi lẫn nhau )

Đối với tôi, các tính năng chính của SBT là:

• Biên dịch nhanh (nhanh hơn fsc).
• Biên dịch / kiểm tra liên tục: lệnh ~testsẽ biên dịch lại và kiểm tra dự án của bạn mỗi khi bạn lưu sửa đổi.
• Tổng hợp chéo và xuất bản chéo, trên một số phiên bản scala.
• Tự động truy xuất các phần phụ thuộc với khả năng tương thích đúng với phiên bản scala.

Nhược điểm là:

• Cú pháp chữ tượng hình có xu hướng không khuyến khích người dùng mới (đặc biệt nếu họ đến từ Java)
• Không có cách nào dễ dàng để xác định một "nhiệm vụ": nếu bạn cần một quy trình xây dựng đặc biệt, bạn sẽ cần phải tìm một plugin hoặc tự viết một plugin.

sbt là một Scala DSL và đối với nó thì Scala là công dân hạng nhất, vì vậy về mặt cơ bản, nó có vẻ là phù hợp.

Nhưng sbt gặp phải những thay đổi lớn không tương thích giữa các phiên bản, điều này khiến cho việc tìm kiếm plugin hoạt động chính xác cho một tác vụ và nó hoạt động trở nên khó khăn.

Cá nhân tôi đã từ bỏ sbt, vì nó gây ra nhiều vấn đề hơn là nó giải quyết được. Tôi thực sự đã chuyển sang gradle.

Đi tìm hình.

Tôi khá mới với gradle và rất mới với sbt - điều tôi thực sự thích về sbt cho đến nay là bảng điều khiển tương tác. Nó cho phép tôi sử dụng các lệnh như 'kiểm tra' để hiểu rõ hơn về những gì đang xảy ra. AFAIK gradle không cung cấp một cái gì đó như thế này atm.

Sbt và gradle, cả hai đều dựa trên các ngôn ngữ được nhập tĩnh .... nhưng sbt có một số ưu điểm:

• hỗ trợ plugin tốt hơn, tự động bổ sung đặc biệt
• tạo nhiệm vụ và quản lý sự phụ thuộc giữa các nhiệm vụ
• sbt đặc biệt phù hợp với các dự án scala theo nghĩa là nó hỗ trợ các bản dựng tăng dần và hầu hết bản thân sbt được viết bằng scala và các định nghĩa về bản dựng sbt được viết bằng scala
• sbt có hỗ trợ shell tương tác với nhiều tác vụ tích hợp hữu ích
• vòng đời mặc định của sbt khá hữu ích và có thể bắt đầu với người mới bắt đầu với khá ít nỗ lực