сравнение sbt и Gradle [закрыто]

я ныряю в Scala и заметил sbt. Я был очень доволен Gradle в Java / groovy проектах, и я знаю, что есть плагин scala для Gradle.

какие могут быть веские причины для предпочтения sbt над Gradle в проекте Scala?

103
gradle sbt scala

5 ответов

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

  • SBT: Айви, с ревизией, которая может быть задана как фиксированная (например, 1.5.2) или как последняя (или динамическая).
    См."Зависимость От Плюща"
    Это означает, что поддержка механизма "- SNAPSHOT " может быть проблематичной, даже если Марк Харра детали этот нить:

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

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

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

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

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

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

58

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

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

минусов являются:

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

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

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

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

идите на фиг.

38

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

4

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

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