ข้อดีและข้อเสียของการใช้ sbt vs maven ในโครงการ Scala [ปิด]

138

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

ปิดให้บริการใน8 ปีที่ผ่านมา

เครื่องมือสร้างใดดีที่สุดสำหรับ Scala ข้อดีและข้อเสียของแต่ละข้อคืออะไร ฉันจะกำหนดว่าจะใช้หนึ่งในโครงการใดได้บ้าง

scala maven sbt

— Konstantin Solomatov
แหล่งที่มา

ฉันเปลี่ยนจาก Maven เป็น Gradle สำหรับโครงการ Scala เนื่องจากการสนับสนุนที่ยอดเยี่ยมสำหรับการสร้างโมดูลแบบหลายโมดูล ประสบการณ์ทวิตเตอร์กับ SBT อธิบายโดยพวกเขาว่า "เจ็บปวดสุดยอด" และพวกเขาพยายามที่จะย้ายออกไปจากมัน (โดย Maven เป็นช่องว่างหยุดในกระบวนการนั้น)

— Ben Manes

อีกคำถามปิดเย็น ...

— Cedric H.

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

— user1888243

ตกลง. โชคดีที่เรามี 2 คำตอบก่อนที่คำถามนี้จะปิด แย่สำหรับผู้ที่จะลงมติปิดคำถามนี้ ...

— hqt

คำตอบ:

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

มิฉะนั้นเพียงใช้ SBT คุณสามารถเข้าถึงการพึ่งพาที่เหมือนกัน (ส่วนที่ดีที่สุดเกี่ยวกับ Maven, IMHO) คุณยังได้รับการรวบรวมที่เพิ่มขึ้นซึ่งมีขนาดใหญ่มาก ความสามารถในการเริ่มเชลล์ในโครงการของคุณซึ่งก็ยอดเยี่ยมเช่นกัน

ScalaMock ใช้งานได้กับ SBT เท่านั้นและคุณอาจต้องการใช้สิ่งนั้นมากกว่าที่จะเป็นไลบรารีการล้อเลียน Java ด้านบนของที่มันมากง่ายต่อการขยาย SBT เนื่องจากคุณสามารถเขียนโค้ดสกาล่าเต็มรูปแบบในการสร้างไฟล์เพื่อให้คุณไม่ต้องไปผ่านทุก rigamarole การเขียนโมโจ

กล่าวโดยย่อคือใช้ SBT ยกเว้นว่าคุณต้องการรวมเข้ากับเซิร์ฟเวอร์ CI ของคุณอย่างแน่นหนา

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

ฉันไม่เห็นด้วยกับสิ่งใด ๆ ข้างต้น แต่เพียงต้องการชี้ให้เห็นว่าฉันกำลังเขียนScalaMock 3ซึ่งเป็นหนึ่งในเป้าหมายหลักที่ทำให้การสนับสนุนระบบการสร้างอื่น ๆ ง่ายขึ้น

— พอล Butcher

เพียงเพื่อความสมบูรณ์เป็นมูลค่าการกล่าวขวัญว่า ScalaMock 2 ทำงานได้ดีกับระบบการสร้างใด ๆ (มันเป็นเพียงขวด) ตราบใดที่คุณไม่จำเป็นต้องใช้ประโยชน์จาก mocks ที่สร้างขึ้น (เช่นตราบใดที่คุณต้องจำลองลักษณะ / ส่วนต่อประสาน) )

— Paul Butcher

scala-maven-plugin ให้การรวบรวมส่วนเพิ่มที่ประหยัดเป็น SBT

— Nikita Volkov

ทำไมพวกเขาไม่เพียงแค่เขียนรวบรวมที่เพิ่มขึ้นสำหรับ Maven? IMHO, sbt เป็นตัวอย่างของโรค NIH ที่ไม่ได้รับการรักษา ...

— Cpt Senkfuss

ทำไมมีปัญหากับ CI เนื่องจาก SBT

— Daniel

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

FWIW มีความคิดเห็นอื่น ๆ ในสกาล่าด้ายรายชื่อผู้รับจดหมายนี้

2c ของฉันคือ: ไปกับ sbt หากคุณไม่มีข้อกำหนดเฉพาะ

สำหรับโครงการง่าย ๆ มันง่ายมาก (คุณไม่จำเป็นต้องมีไฟล์บิลด์จนกว่าคุณจะต้องพึ่งพา)
มันเป็นเรื่องธรรมดาที่ใช้ข้ามโครงการโอเพ่นซอร์สสกาล่า คุณสามารถเรียนรู้เกี่ยวกับการกำหนดค่าได้อย่างง่ายดายโดยดูที่โครงการของผู้อื่น นอกจากนี้ยังมีหลายโครงการที่สมมติว่าคุณใช้ sbt และให้คำแนะนำการคัดลอก + วางพร้อมสำหรับการเพิ่มพวกเขาเป็นการพึ่งพาโครงการของคุณ
ถ้าคุณใช้ IntelliJ IDEA มันสามารถรวมเข้าด้วยกันได้อย่างสมบูรณ์ คุณสามารถมีการใช้ความคิด SBTอย่างต่อเนื่องเพื่อรวบรวมโครงการของคุณและในทางกลับกันคุณสามารถใช้ SBT ได้อย่างรวดเร็วสร้างโครงการ IDEA สุดท้ายมีประโยชน์อย่างยิ่งหากคุณอยู่ในวงจร 'ภาพรวม' โดยขึ้นอยู่กับห้องสมุดอื่น ๆ ของคุณซึ่งถูกชนจากรุ่นรองเป็นรุ่นรอง - เพียงปิดโครงการอัปเดตเวอร์ชันในไฟล์บิลด์ใหม่gen-ideaงานและเปิดโครงการอีกครั้ง: อัพเดตเสร็จแล้ว
มาพร้อมกับงานมากที่สุดที่คุณจะต้อง ( compile, test, run, doc, publish-local, console) - The consoleเป็นหนึ่งในคุณสมบัติที่ดีที่สุด
บางคนเน้นคุณลักษณะที่สามารถพึ่งพาแหล่งเก็บข้อมูลโดยตรงจาก GitHub ฉันไม่ได้ใช้สิ่งนี้จึงไม่สามารถแสดงความคิดเห็นได้ที่นี่

บางคนเกลียด SBT เพราะใช้ Ivy สำหรับการจัดการการพึ่งพา (ฉันไม่สามารถแสดงความคิดเห็นในข้อดีและข้อเสียของมัน แต่ส่วนใหญ่มันไม่ใช่ปัญหา) บางคนเกลียด SBT เพราะคุณระบุไฟล์สร้างในแง่ของ Scala DSL แทน XML บางคนผิดหวังที่รูปแบบของ sbt เปลี่ยนจาก v0.7 เป็น v0.10 แต่แน่นอนว่าการย้ายข้อมูลจะไม่ส่งผลกระทบต่อคุณหากคุณเริ่มต้นจากศูนย์

— 0__
แหล่งที่มา

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

— xiefei

น่าเสียดายที่คำถามนี้ถูกปิดฉันแน่ใจว่ามีความแตกต่างจริงเช่น: ข้อความที่ตัดตอนมาจากหนังสือแมนนิ่งเกี่ยวกับ SBT: "หากมีการพึ่งพาระหว่างเป้าหมาย Maven (กล่าวว่าเป้าหมายหนึ่งสร้างไฟล์ที่ผู้อื่นใช้) จากนั้นคุณไม่สามารถสร้างงานขนานกับ Maven ด้วย sbt คุณต้องระบุการพึ่งพาอย่างชัดเจนระหว่างงานสิ่งนี้จะช่วยให้ sbt ทำงานในแบบขนานโดยเริ่มต้นหากงาน A ขึ้นอยู่กับ B และ C ขึ้นอยู่กับ B แล้ว sbt run task B แล้วรัน A และ C ขนานกัน " หวังว่าความคิดเห็นนี้จะช่วยให้ผู้อ่านบางคน

— jhegedus

ฉันพบว่าหัวข้อนี้มีประโยชน์มาก ฉันมักจะคิดว่าผู้ดูแล Stackoverflow ปิดเธรดอย่างกระตือรือร้นเกินไป ใครสนใจว่าพวกเขา "ปิดหัวข้อ" เมื่อพวกเขามักจะตรงกับสิ่งที่ผู้ใช้กำลังค้นหา (และค้นหาผ่านการค้นหาเว็บ) มันเหมือนกับว่าวัยรุ่น Stackoverflow กำลังพยายามที่จะสร้างจงใจxkcd 979

— วิลล์

@Ville ความคิดของฉันเช่นกัน Downvoting การแก้ไขและการปิดได้กลายเป็นก้าวร้าวเกินไป

— ankush981

สำหรับทุกคนที่ดูสิ่งนี้การร้องเรียนของ @ xiefei ได้รับการแก้ไขแล้ว SBT ทำให้ตัวดำเนินการ / ไวยากรณ์แบบกำหนดเองลดลงจำนวนมากและคำสั่งในไฟล์ / sbt ไม่ต้องการการแยกช่องว่างอีกต่อไป

— Grogs