порівняння sbt та Gradle [закрито]

Я занурився в Scala і помітив sbt. Я дуже задоволений Gradle в проектах java / groovy, і знаю, що для Gradle є плагін Scala.

Які можуть бути вагомі причини надати перевагу sbt над Gradle у проекті Scala?

Зауважте, що однією з ключових відмінностей між SBT і Gradle є управління залежністю :

• SBT : Плющ , з переглядом, який може бути наданий як фіксований (наприклад, 1.5.2) або як останній (або динамічний).
  Див. " Залежність від плюща ".
  Це означає, що підтримка механізму "-SNAPSHOT" може бути проблематичною, навіть якщо деталі Марка Харра в цій темі :

Це правда, кеш може заплутатися, але це неправда, що Айві не розуміє вирішення знімків. Євген пояснив це в іншій темі, можливо, у списку адміністратора. Виникає проблема з автоматичним оновленням sbt, яке було вирішено в 0.12.

Те, що Ivy не підтримує, наскільки я знаю, публікує знімки таким чином, як це робить Maven. Я вважаю, що я це заявив в іншому місці, але якщо хтось хоче покращити ситуацію, я вважаю, що найкраще витратити зусилля, працюючи з командою Gradle, щоб повторно використовувати свій код управління залежністю.

• Gradle : Ця тема згадує ( Peter Niederwieser ):

Щоб повідомити вам, проблеми із залежними знімками Ivy та Maven були однією з причин, чому Gradle врешті-решт замінив Ivy власним кодом управління залежністю. Це було велике завдання, але принесло нам багато добра.

Цей твіт згадує, що вся ситуація може розвиватися в майбутньому:

У минулому Марк заявив, що йому було цікаво використовувати Gradle замість Ivy для SBT.

(обидва інструменти можуть вчитися один у одного )

Для мене ключовими особливостями SBT є:

• Швидка компіляція (швидше, ніж fsc).
• Постійна компіляція / тестування: команда ~testбуде перекомпілювати та перевіряти проект, кожен раз, коли ви зберігаєте модифікацію.
• Крос-компіляція та крос-публікація у кількох версіях шкали.
• Автоматичне отримання залежностей із правильною сумісністю версії scala.

Мінуси:

• Ієрогліфічний синтаксис, який, як правило, відлякує нових користувачів (особливо якщо вони походять з Java)
• Непростий спосіб визначити "завдання": якщо вам потрібна спеціальна процедура складання, вам потрібно буде або знайти плагін, або самостійно написати плагін.

sbt - це Scala DSL, і для нього Scala є першокласним громадянином, тому в принципі це, здається, добре підходить.

Але sbt страждає від великих несумісних змін між версіями, через що важко знайти правильний робочий плагін для завдання та змусити його працювати.

Я особисто відмовився від sbt, оскільки це викликало більше проблем, ніж вирішувало. Я фактично перейшов на градле.

Піди розберися.

Я досить новачок в gradle, і дуже новий в sbt - що мені дуже подобається в sbt поки що - це інтерактивна консоль. Це дозволяє мені використовувати команди типу "перевірити", щоб краще зрозуміти, що відбувається. AFAIK gradle не надає такого типу атма.

Обидва Sbt і gradle базуються на статично введених мовах .... але sbt має мало переваг:

• краща підтримка плагінів, спеціально автоматичні додатки
• створення завдань та управління залежностями між завданнями
• sbt спеціально підходить для проектів scala в тому сенсі, що він підтримує поступові побудови, і більша частина самого sbt написана у масштабі scala, а визначення sbt build - у scala.
• sbt має інтерактивну підтримку оболонки з багатьма корисними вбудованими завданнями
• Життєвий цикл за замовчуванням sbt є досить корисним і може почати початківців із значно меншими зусиллями