เปรียบเทียบ sbt และ Gradle [ปิด]

111

ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบได้ด้วยข้อเท็จจริงและการอ้างอิงโดยแก้ไขโพสต์นี้

ปิดให้บริการใน4 ปีที่แล้ว

ฉันกำลังดำน้ำใน Scala และสังเกตเห็น sbt ฉันค่อนข้างพอใจกับ Gradle ในโปรเจ็กต์ java / groovy และฉันรู้ว่ามีปลั๊กอิน scala สำหรับ Gradle

อะไรคือเหตุผลที่ดีที่จะชอบ sbt มากกว่า Gradle ในโครงการ Scala

scala sbt gradle

— ฮันส์เวสเตอร์บีค
แหล่งที่มา

SBT ในบางแง่ก็เหมือนกลุ่มถ้าคุณคร่ำครวญคุณจะพอใจ นอกจากนี้ยังมี maven และ lein (ถูกสร้างขึ้นสำหรับ clojure แต่ใช้ได้กับ scala ด้วย)

— om-nom-nom

18

อย่ารู้สึกกดดันที่ต้องย้ายไป SBT สมาชิกชุมชน Scala ที่รู้จักกันดีบางคนใช้ Gradle ให้ใช้ SBT เป็นการทดสอบโดยรู้ว่าคุณสามารถใช้ Gradle แทนได้

— Daniel C. Sobral

6

ขอบคุณทุกคน ... เมื่ออ่านข้อมูลเชิงลึกของคุณแล้วฉันจะติดกับ Gradle สำหรับฉันแล้วนั่นคือจุดที่ความพยายามในการสร้างเครื่องมือส่วนใหญ่สำหรับพื้นที่ JVM จะเป็นไปได้เมื่อเราทิ้ง Maven ไว้เบื้องหลัง

— Hans Westerbeek

10

เป็นเรื่องน่ารำคาญที่คำถามนี้ถูกระบุว่าเป็น 'ตามความคิดเห็น' ที่นี่อาจเป็นเพราะคนที่ไม่ได้ทำงานในพื้นที่ JVM ตลอดเวลา (และขาดการกำกับดูแล) คำตอบด้านล่างเป็นข้อเท็จจริงและปราศจากสิ่งศักดิ์สิทธิ์ของสงคราม

— Hans Westerbeek

4

ไม่คำตอบเหล่านั้นส่วนใหญ่เป็นข้อความของข้อเท็จจริงที่พิสูจน์ได้ไม่ใช่ความคิดเห็น แม้ว่าคำถามนี้อาจดึงดูดคำตอบที่ไม่เป็นประโยชน์ แต่ในความเป็นจริงก็ไม่ได้ทำเช่นนั้น ควรเปิดเป็นคำอธิบายที่เป็นประโยชน์เกี่ยวกับความแตกต่างที่แท้จริงระหว่างเครื่องมือ

— erickson

61

โปรดทราบว่าความแตกต่างที่สำคัญอย่างหนึ่งระหว่าง SBT และ Gradle คือการจัดการการพึ่งพา :

SBT : Ivyพร้อมการแก้ไขซึ่งสามารถกำหนดให้เป็นแบบคงที่ (1.5.2 เป็นต้น) หรือล่าสุด (หรือไดนามิก)
ดู " Ivy Dependency "
นั่นหมายความว่าการสนับสนุนกลไก "-SNAPSHOT" อาจเป็นปัญหาได้แม้ว่ารายละเอียดของMark Harrahในชุดข้อความนี้ :

เป็นเรื่องจริงที่แคชอาจสับสนได้ แต่ไม่เป็นความจริงที่ Ivy ไม่เข้าใจการแก้ไขสแนปชอต ยูจีนอธิบายประเด็นนี้ในหัวข้ออื่นบางทีอาจอยู่ในรายชื่อผู้ดูแลระบบ มีปัญหากับการอัปเดตอัตโนมัติของ sbt ที่ได้รับการแก้ไขใน 0.12

สิ่งที่ Ivy ไม่สนับสนุนเท่าที่ฉันรู้คือการเผยแพร่ภาพรวมในลักษณะที่ Maven ทำ ฉันเชื่อว่าฉันได้ระบุสิ่งนี้ไว้ที่อื่น แต่ถ้าใครต้องการปรับปรุงสถานการณ์ความคิดเห็นของฉันคือความพยายามที่ดีที่สุดคือการทำงานร่วมกับทีม Gradle เพื่อนำรหัสการจัดการการพึ่งพากลับมาใช้ใหม่

Gradle : หัวข้อนี้กล่าวถึง ( Peter Niederwieser ):

เพียงเพื่อแจ้งให้คุณทราบปัญหาเกี่ยวกับการพึ่งพาสแน็ปช็อตของ Ivy และ Maven เป็นสาเหตุหนึ่งที่ทำให้ Gradle แทนที่ Ivy ด้วยรหัสการจัดการการพึ่งพาของตัวเองในที่สุด มันเป็นงานใหญ่ แต่ทำให้เรามีความดีมากมาย

ทวีตนี้ระบุว่าสถานการณ์ทั้งหมดสามารถพัฒนาได้ในอนาคต:

มาร์คบอกในอดีตว่าเขาสนใจที่จะใช้ Gradle แทน Ivy สำหรับ SBT

(เครื่องมือทั้งสองสามารถเรียนรู้จากกันและกัน )

— VonC
แหล่งที่มา

1

ความไม่สะดวกที่สุดที่ฉันเคยพบคือ sbt คือคุณไม่สามารถระบุกฎที่จะไม่คอมไพล์ใหม่ทุกครั้งที่มีการกล่าวถึง กฎในตัวสำหรับ java และ scala มีฟังก์ชันนี้ แต่จะไม่ถูกเปิดเผยสำหรับการเขียนกฎที่กำหนดเอง ดังนั้นทุกครั้งที่คุณสร้างไฟล์โปรแกรมหรือเอกสารและแม้ว่าคุณจะสร้างไฟล์ jar งานของคุณจะถูกดำเนินการในการโทรแต่ละครั้งไม่ว่าจะมีการเปลี่ยนแปลงแหล่งที่มาก็ตาม แม้แต่ make ก็ฉลาดพอ แต่ไม่ใช่ sbt

— ayvango

1

@ayvango ไม่ใช่อย่างนั้นสำหรับ sbt ในปัจจุบัน มีปลั๊กอินมากมายที่ใช้ฟังก์ชันนี้เช่นandroid-sdk-plugin

— dant3

คุณรู้หรือไม่ว่า API ใดที่ใช้สำหรับการทำงานนั้น?

— Ayvango

ดังนั้นนี่คือสิ่งที่ไม้เลื้อยขาดเมื่อเปรียบเทียบกับทั้ง maven & gradle? นั่นเป็นเรื่องแปลก

— tribbloid

53

สำหรับฉันคุณสมบัติที่สำคัญของ SBT คือ:

คอมไพล์เร็ว (เร็วกว่าfsc)
การคอมไพล์ / การทดสอบอย่างต่อเนื่อง: คำสั่ง~testจะคอมไพล์ใหม่และทดสอบคุณฉายทุกครั้งที่คุณบันทึกการแก้ไข
การคอมไพล์ข้ามและการเผยแพร่ข้ามเวอร์ชันสกาลาหลายเวอร์ชัน
เรียกข้อมูลการอ้างอิงโดยอัตโนมัติด้วยความเข้ากันได้ของเวอร์ชันสกาล่าที่ถูกต้อง

ข้อเสียคือ:

ไวยากรณ์อักษรอียิปต์โบราณที่มีแนวโน้มที่จะกีดกันผู้ใช้ใหม่ (โดยเฉพาะอย่างยิ่งถ้าพวกเขามาจาก Java)
ไม่มีวิธีง่ายๆในการกำหนด "งาน": หากคุณต้องการขั้นตอนการสร้างพิเศษคุณจะต้องหาปลั๊กอินหรือเขียนปลั๊กอินด้วยตัวเอง

— กระบวนทัศน์
แหล่งที่มา

ฉันแก้ไขหรือไม่ว่ามี / จำเป็นสำหรับคุณสมบัติการคอมไพล์ / การเผยแพร่ข้ามเนื่องจากปัญหาที่สกาล่ามีเกี่ยวกับความไม่ลงรอยกันของไบนารีย้อนหลัง

— Hans Westerbeek

1

ใช่. และปัญหาเหล่านี้อาจเกิดขึ้นอีกเมื่อย้ายไปที่ Scala 2.10

— paradigmatic

1

มีความแตกต่างอีกสองอย่างที่ฉันเพิ่ม: * ใน SBT การจัดการการอ้างอิงด้วยตนเองง่ายกว่า IMO * นักวิ่งทดสอบ SBT ดูเหมือนเร็วกว่า ฉันสงสัยว่ามีการเกิดขึ้นพร้อมกันอย่างมีเล่ห์เหลี่ยมที่นี่ แต่ฉันเดาได้ SBT ดูเหมือนจะเป็นผลิตภัณฑ์ที่มีความสามารถมากกว่า แต่ค่อนข้างโตเต็มที่

— Rick-777

25

+1 สำหรับข้อเสียของ 'ไวยากรณ์อักษรอียิปต์โบราณ' นั่นคือการจับที่ใหญ่ที่สุดของฉันกับ SBT การทำงานหนักเกินไปของผู้ปฏิบัติงานจะนำไปสู่การละเมิดเสมอ: - /

— Ron Dahlgren

7

ไวยากรณ์ SBT ที่เป็นความลับนำเสนอสิ่งที่เลวร้ายที่สุดในสกาลา Gradle ขึ้นอยู่กับรูปแบบโดเมนที่คิดมาเป็นอย่างดีและไวยากรณ์แบบตรงไปตรงมา

— nemoo

41

sbt เป็น Scala DSL และ Scala เป็นพลเมืองชั้นหนึ่งดังนั้นโดยทั่วไปแล้วดูเหมือนว่าจะเข้ากันได้ดี

แต่ sbt ต้องทนทุกข์ทรมานจากการเปลี่ยนแปลงที่สำคัญระหว่างเวอร์ชันที่เข้ากันไม่ได้ซึ่งทำให้ยากที่จะหาปลั๊กอินที่ใช้งานได้สำหรับงานและทำให้มันใช้งานได้

ฉันยอมแพ้กับ sbt เป็นการส่วนตัวเนื่องจากมันทำให้เกิดปัญหามากกว่าที่จะแก้ไขได้ ฉันเปลี่ยนไปใช้ gradle จริงๆ

ไปคิด

— Jens Schauder
แหล่งที่มา

2

เท่าที่ฉันรู้มีการเปลี่ยนแปลงที่สำคัญเพียงอย่างเดียวคือเมื่อ sbt เปลี่ยนจาก 0.7.x เป็น 0.1.x

— om-nom-nom

1

หากคุณใช้ปลั๊กอินสำหรับ sbt 0.11.2 แล้วไปที่ sbt 0.12 คุณต้องรอให้ผู้เขียนปลั๊กอินรวบรวมเวอร์ชันใหม่หรือทำเอง idea-sbt เป็นตัวอย่างหนึ่ง

— fmpwizard

4

@fmpwizard sbt 0.12 line ยังไม่ได้ขาย ... หยุดแพร่กระจาย FUD

— paradigmatic

3

ไม่ใช่ sbt ที่ใช้ไม่ได้ทีมของเราใช้มัน แต่ความคิดเห็นของฉันคือการสนับสนุนคำตอบนี้ซึ่งกล่าวว่า "... แต่ sbt ได้รับความทุกข์ทรมานจากการเปลี่ยนแปลงที่เข้ากันไม่ได้ที่สำคัญระหว่างเวอร์ชันซึ่งทำให้ยากที่จะหาปลั๊กอินที่ใช้งานได้สำหรับงานและทำให้มันใช้งานได้ ... " เหมือนที่คุณสังเกตเห็น ฉันไม่สามารถใช้ปลั๊กอิน scct ได้ฉันต้องแก้ไข (ใช่การเปลี่ยนแปลงเล็กน้อย แต่จากนั้นฉันต้องเผยแพร่ที่ไหนสักแห่งเพื่อให้ทั้งทีมของฉันเข้าถึงได้) ความเจ็บปวดโดยไม่มีเหตุผลที่ดี

— fmpwizard

3

คุณสามารถทำการคอมไพล์ข้ามสำหรับ Scala เวอร์ชันต่างๆโดยใช้ gradle ได้หรือไม่?

— Machisuji

4

ฉันค่อนข้างใหม่สำหรับ gradle และใหม่มากสำหรับ sbt - สิ่งที่ฉันชอบเกี่ยวกับ sbt จนถึงตอนนี้คือคอนโซลแบบโต้ตอบ ช่วยให้ฉันใช้คำสั่งเช่น 'ตรวจสอบ' เพื่อให้เข้าใจสิ่งที่เกิดขึ้นได้ดีขึ้น AFAIK gradle ไม่มีตู้เอทีเอ็มแบบนี้

— Eugenevd
แหล่งที่มา

-11

Sbt และ gradle ทั้งสองใช้ภาษาที่พิมพ์แบบคงที่ .... แต่ sbt มีข้อดีบางประการ:

การสนับสนุนปลั๊กอินที่ดีขึ้น autoplugins พิเศษ
การสร้างงานและการจัดการการพึ่งพาระหว่างงาน
sbt เหมาะเป็นพิเศษกับโครงการ scala ในแง่ที่ว่ามันรองรับการสร้างที่เพิ่มขึ้นและ sbt ส่วนใหญ่เขียนด้วย scala และคำจำกัดความของการสร้าง sbt ถูกเขียนด้วยสกาลา
sbt มีการสนับสนุนเชลล์แบบโต้ตอบพร้อมงานในตัวที่มีประโยชน์มากมาย
วงจรชีวิตเริ่มต้น sbt มีประโยชน์มากและสามารถเริ่มต้นมือใหม่ได้โดยใช้ความพยายามน้อยลง

— Saby
แหล่งที่มา

1

Gradle ขึ้นอยู่กับ groovy ซึ่งไม่ใช่ภาษาที่พิมพ์แบบคงที่

— Vistritium

Gradle ทำการจัดการการพึ่งพาระหว่างงานมันง่ายที่สุดเท่าที่จะเป็นไปได้ในการสร้างงานฉันไม่รู้ว่าจะเขียนปลั๊กอินได้ง่ายกว่าการ gradle ซึ่งสามารถใช้ปลั๊กอินที่มีความซับซ้อน, Java, gradle และอื่น ๆ ได้

— Johnride