Сравнение sbt и Gradle

Ответ 1

Обратите внимание, что одним ключевым отличием между SBT и Gradle является его управление зависимостями:

• SBT: Ivy, с aa revision, который может быть задан как фиксированный (например, 1.5.2) или как последний (или динамический). См. "Зависимость Айви "
  Это означает, что поддержка механизма "-SNAPSHOT" может быть проблематичной, хотя Mark Harrah детализирует в этот поток:

Правда, кеш может запутаться, но неправда, что Ivy не понимает разрешения снимков. Евгений объяснил это в другом потоке, возможно, в списке администраторов. Возникла проблема с автоматическим обновлением sbt, которое было адресовано в 0.12.

Что Айви не поддерживает, насколько я знаю, публикует моментальные снимки так, как это делает Maven. Я считаю, что я сказал об этом в другом месте, но если кто-то хочет улучшить ситуацию, я считаю, что лучше всего потратить усилия на работу с командой Gradle, чтобы повторно использовать свой код управления зависимостями.

• Gradle: Этот поток упоминает (Peter Niederwieser):

Просто чтобы вы знали, проблемы с зависимостями моментальных снимков Ivy и Maven были одной из причин, почему Gradle в конечном итоге заменил Ivy собственным кодом управления зависимостями. Это была большая задача, но принесло нам много пользы.

В этом твитте упоминается, что вся ситуация может развиваться в будущем:

Марк сказал в прошлом, что он заинтересован в использовании Gradle вместо Ivy для SBT.

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

Ответ 2

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

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

Недостатки:

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

Ответ 3

sbt является DSL Scala и для него Scala является гражданином первого класса, поэтому в принципе это кажется хорошим подспорьем.

Но sbt страдает от серьезных несовместимых изменений между версиями, что затрудняет поиск правильного рабочего плагина для задачи и заставить его работать.

Я лично отказался от sbt, так как это вызывало больше проблем, чем решение. Я действительно переключился на gradle.

Показать рисунок.

Ответ 4

Я новичок в gradle и очень новичок в sbt - что мне действительно нравится в sbt до сих пор - это интерактивная консоль. Это позволяет мне использовать команды, такие как "проверка", чтобы лучше понять, что происходит. AFAIK gradle не предоставляет что-то вроде этого atm.

Ответ 5

Sbt и gradle, оба основаны на статически типизированных языках.... но sbt имеет несколько преимуществ:

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