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

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

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

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

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

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

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

• Gradle : В этой ветке упоминается ( Питер Нидервизер ):

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

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

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

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

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

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

Минусы:

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

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

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

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

Иди разбери.

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

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

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