membandingkan sbt dan Gradle [tertutup]


110

Saya menyelam ke Scala dan memperhatikan sbt. Saya cukup senang dengan Gradle di proyek java / groovy, dan saya tahu ada plugin scala untuk Gradle.

Apa alasan bagus untuk lebih memilih sbt daripada Gradle dalam proyek Scala?


SBT dalam arti tertentu seperti Vim: jika Anda berhasil, Anda akan senang. Dan omong-omong, ada juga maven dan lein (diciptakan untuk clojure, tapi bisa juga digunakan dengan scala).
om-nom-nom

18
Jangan merasa tertekan untuk pindah ke SBT. Beberapa anggota komunitas Scala yang terkenal menggunakan Gradle. Sebagai gantinya, gunakan SBT sebagai eksperimen, karena Anda tahu bahwa Anda bisa menggunakan Gradle saja.
Daniel C. Sobral

6
terima kasih semua ... Setelah membaca wawasan Anda, saya akan tetap menggunakan Gradle. Menurut saya, di situlah sebagian besar upaya build-tool untuk ruang JVM akan dilakukan saat kita meninggalkan Maven.
Hans Westerbeek

10
Sangat menjengkelkan bahwa pertanyaan ini ditandai sebagai 'berbasis opini' di sini, mungkin oleh orang-orang yang tidak bekerja di ruang JVM sepanjang waktu (dan karena itu tidak memiliki pengawasan). Jawaban di bawah ini faktual dan tanpa perang-suci-isme.
Hans Westerbeek

4
Tidak, jawaban tersebut pada dasarnya adalah pernyataan dari fakta yang dapat diuji, bukan opini. Meskipun pertanyaan ini dapat menarik jawaban yang tidak membantu, pada kenyataannya pertanyaan ini tidak berhasil. Ini harus tetap terbuka sebagai deskripsi yang berguna tentang perbedaan aktual antara alat.
erickson

Jawaban:


61

Perhatikan bahwa satu perbedaan utama antara SBT dan Gradle adalah manajemen ketergantungannya :

  • SBT : Ivy , dengan revisi yang dapat diberikan sebagai revisi tetap (1.5.2, misalnya) atau sebagai yang terbaru (atau dinamis).
    Lihat " Ivy Dependency "
    Artinya dukungan mekanisme "-SNAPSHOT" bisa jadi bermasalah, padahal Mark Harrah detailnya di thread ini :

Memang benar cache bisa membingungkan, tetapi tidak benar bahwa Ivy tidak memahami menyelesaikan snapshot. Eugene menjelaskan hal ini di utas lain, mungkin di daftar admin. Ada masalah dengan pembaruan otomatis sbt yang telah diatasi di 0.12.

Yang tidak didukung Ivy, sejauh yang saya tahu, adalah menerbitkan snapshot seperti yang dilakukan Maven. Saya yakin saya telah menyatakan ini di tempat lain, tetapi jika ada yang ingin memperbaiki situasi, pendapat saya adalah upaya terbaik dihabiskan dengan bekerja dengan tim Gradle untuk menggunakan kembali kode manajemen ketergantungan mereka.

Sekadar memberi tahu Anda, masalah dengan dependensi snapshot Ivy dan Maven adalah salah satu alasan mengapa Gradle pada akhirnya mengganti Ivy dengan kode manajemen dependensinya sendiri. Itu adalah tugas besar, tapi memberi kami banyak kebaikan.

Tweet ini menyebutkan bahwa semua situasi dapat berkembang di masa depan:

Mark mengatakan sebelumnya bahwa dia tertarik menggunakan Gradle daripada Ivy untuk SBT.

(kedua alat dapat saling belajar )


1
Ketidaknyamanan yang paling saya temui adalah sbt adalah Anda tidak dapat menentukan aturan untuk tidak mengkompilasi ulang setiap kali disebutkan. Aturan built-in untuk java dan scala memiliki fungsionalitas ini tetapi tidak terekspos untuk penulisan aturan kustom. Jadi setiap kali Anda membuat file program atau dokumentasi dan bahkan jika Anda membuat file jar, tugas Anda akan dilakukan pada setiap panggilan terlepas dari perubahan apa pun pada sumber yang benar-benar dilakukan. Bahkan membuat cukup pintar, tetapi tidak sbt
ayvango

1
@ayvango Ini bukan kasus sbt saat ini. Ada banyak plugin yang memanfaatkan fungsi ini, seperti android-sdk-plugin
dant3

Apakah Anda tahu API apa yang digunakan untuk fungsi itu?
ayvango

jadi ini adalah sesuatu yang kurang dari ivy jika dibandingkan dengan maven & gradle? Aneh
tribbloid

53

Bagi saya, fitur utama SBT adalah:

  • Kompilasi cepat (lebih cepat dari fsc).
  • Kompilasi / pengujian berkelanjutan: perintah ~testakan mengkompilasi ulang dan menguji proyek Anda setiap kali Anda menyimpan modifikasi.
  • Kompilasi silang dan penerbitan silang, di beberapa versi skala.
  • Secara otomatis mengambil dependensi dengan kompatibilitas versi skala yang benar.

Kerugiannya adalah:

  • Sintaks hieroglif yang cenderung membuat pengguna baru enggan (terutama jika mereka berasal dari Java)
  • Tidak ada cara mudah untuk mendefinisikan "tugas": jika Anda memerlukan prosedur build khusus, Anda perlu mencari plugin, atau menulis plugin sendiri.

Apakah saya benar bahwa ada / perlu fitur kompilasi silang / penerbitan karena masalah yang dialami Scala dengan inkompatibilitas biner mundur?
Hans Westerbeek

1
Iya. Dan masalah ini dapat terjadi lagi saat pindah ke Scala 2.10.
paradigmatis

1
Ada dua perbedaan lagi yang akan saya tambahkan: * Di SBT, lebih mudah untuk mengatur sendiri dependensi, IMO. * Pelari tes SBT tampaknya lebih cepat; Saya curiga ada beberapa konkurensi licik yang terlibat di sini, tetapi saya menebak-nebak. SBT sepertinya merupakan produk yang lebih mampu tetapi kurang matang.
Rick-777

25
1 untuk sisi negatif 'sintaks hieroglif'. Itu keluhan terbesar saya dengan SBT. Kelebihan beban operator selalu mengarah pada penyalahgunaan: - /
Ron Dahlgren

7
Sintaks SBT samar menampilkan yang terburuk dalam skala. Gradle didasarkan pada model domain yang dipikirkan dengan matang dan sintaks lurus ke depan.
nemoo

40

sbt adalah Scala DSL dan untuk itu Scala adalah warga negara kelas satu, jadi pada prinsipnya tampaknya cocok.

Tetapi sbt menderita perubahan besar yang tidak kompatibel antar versi, yang membuatnya sulit untuk menemukan plugin yang berfungsi dengan benar untuk suatu tugas dan membuatnya berfungsi.

Saya pribadi menyerah pada sbt, karena itu menyebabkan lebih banyak masalah daripada diselesaikan. Saya benar-benar beralih ke gradle.

Sosok pergi.


2
Sejauh yang saya tahu, hanya ada satu perubahan yang sangat besar: ketika sbt beralih dari 0.7.x ke 0.1.x
om-nom-nom

1
Jika Anda menggunakan plugin untuk sbt 0.11.2, lalu pergi ke sbt 0.12, Anda harus menunggu pembuat plugin untuk mengkompilasi versi baru atau melakukannya sendiri. idea-sbt adalah salah satu contohnya.
fmpwizard

4
@fmpwizard Baris sbt 0.12 belum dirilis ... Berhenti menyebarkan FUD.
paradigmatis

3
Bukan sbt yang tidak mungkin digunakan, tim kami menggunakannya. Tetapi komentar saya adalah untuk mendukung jawaban ini, yang mengatakan "... Tapi sbt mengalami perubahan besar yang tidak kompatibel di antara versi, yang membuatnya sulit untuk menemukan plugin yang berfungsi dengan benar untuk suatu tugas dan membuatnya berfungsi ..." Seperti yang Anda perhatikan , Saya tidak bisa hanya menggunakan plugin scct, saya harus memodifikasinya (ya perubahan kecil, tapi kemudian saya harus menerbitkannya di suatu tempat sehingga seluruh tim saya dapat mengaksesnya) Sakit tanpa alasan yang jelas.
fmpwizard

3
Apakah Anda dapat melakukan kompilasi silang untuk berbagai versi Scala menggunakan gradle?
Machisuji

4

Saya cukup baru mengenal gradle, dan sangat baru dalam sbt - yang sangat saya sukai dari sbt sejauh ini adalah konsol interaktif. Ini memungkinkan saya menggunakan perintah seperti 'memeriksa' untuk mendapatkan gambaran yang lebih baik tentang apa yang sedang terjadi. AFAIK gradle tidak menyediakan atm seperti ini.


-11

Sbt dan gradle, keduanya didasarkan pada bahasa yang diketik secara statis .... tetapi sbt memiliki beberapa keunggulan:

  • dukungan plugin yang lebih baik, khususnya autoplugin
  • pembuatan tugas dan manajemen ketergantungan antar tugas
  • sbt secara khusus sesuai dengan proyek scala dalam arti mendukung incremental build dan sebagian besar sbt itu sendiri ditulis dalam scala dan definisi build sbt ditulis dalam scala
  • sbt memiliki dukungan shell interatif dengan banyak tugas built-in yang berguna
  • Siklus hidup default sbt cukup berguna dan dapat memulai pemula dengan sedikit usaha

1
Gradle didasarkan pada groovy yang bukan merupakan bahasa yang diketik secara statis.
Vistritium

Gradle melakukan manajemen ketergantungan antar tugas, semudah mungkin membuat tugas, saya tidak tahu bagaimana bisa lebih mudah untuk menulis plugin daripada untuk gradle yang dapat menggunakan groovy, Java, plugin gradle dan mungkin banyak lagi.
Johnride
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.