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


110

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

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


SBT в некотором смысле похож на Vim: если вы его попробуете, вы будете довольны. И, кстати, есть еще maven и lein (был создан для clojure, но работает и со scala).
om-nom-nom

18
Не испытывайте давления, чтобы перейти на SBT. Некоторые известные члены сообщества Scala используют Gradle. Вместо этого используйте SBT в качестве эксперимента, зная, что вместо этого вы можете просто использовать Gradle.
Daniel C. Sobral

6
спасибо всем ... Прочитав ваши идеи, я буду придерживаться Gradle. Мне кажется, что именно здесь будет сосредоточена большая часть усилий по созданию инструментов для пространства JVM, когда мы оставим Maven позади.
Hans Westerbeek

10
Досадно, что этот вопрос здесь помечается как «основанный на мнении», вероятно, людьми, которые не работают в JVM-пространстве все время (и, следовательно, не имеют должного контроля). Приведенные ниже ответы основаны на фактах и ​​лишены священной войны.
Ханс Вестербик,

4
Нет, эти ответы в основном представляют собой утверждения проверяемых фактов, а не мнения. Хотя этот вопрос может вызвать бесполезные ответы, на самом деле этого не произошло. Он должен оставаться открытым как полезное описание реальных различий между инструментами.
erickson

Ответы:


61

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

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

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

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

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

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

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

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


1
Самым большим неудобством, с которым я когда-либо встречался, является sbt, это то, что вы не могли указать правило, чтобы оно не перекомпилировалось каждый раз, когда оно упоминается. Встроенные правила для java и scala обладают этой функциональностью, но не используются для написания собственных правил. Таким образом, каждый раз, когда вы создаете программный файл или документацию, и даже если вы генерируете файл jar, ваша задача будет выполняться при каждом вызове, независимо от того, были ли действительно сделаны какие-либо изменения в источниках. Даже make достаточно умен, но не sbt
айванго

1
@ayvango В наше время это не так. Есть много плагинов, которые используют эту функциональность, например android-sdk-plugin
dant3

Вы знаете, какой API используется для этой функции?
Айванго

так что это то, чего не хватает плющу по сравнению с maven и gradle? Это странно
трибблоид

53

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

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

Минусы:

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

Правильно ли я, что существует / была необходимость в функции кросс-компиляции / публикации из-за проблем, которые у Scala были с обратной двоичной несовместимостью?
Hans Westerbeek

1
Да. И эти проблемы могут повториться снова при переходе на Scala 2.10.
paradigmatic

1
Я бы добавил еще два отличия: * В SBT проще самостоятельно управлять зависимостями, IMO. * Запуск теста SBT кажется быстрее; Я подозреваю, что здесь задействован хитрый параллелизм, но я предполагаю. SBT кажется более способным, но менее зрелым продуктом.
Rick-777

25
+1 за обратную сторону «иероглифического синтаксиса». Это моя самая большая проблема с SBT. Перегрузка оператора всегда приводит к злоупотреблениям: - /
Рон Дальгрен

7
Загадочный синтаксис SBT обнаруживает худшее в scala. Gradle основан на хорошо продуманной модели предметной области и прямом синтаксисе.
nemoo

40

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

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

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

Иди разбери.


2
Насколько я знаю, было только одно очень серьезное изменение: когда sbt переключился с 0.7.x на 0.1.x
om-nom-nom

1
Если вы используете плагин для sbt 0.11.2, а затем переходите на sbt 0.12, вам нужно дождаться, пока автор плагина скомпилирует новую версию или сделает это самостоятельно. idea-sbt - один из примеров.
fmpwizard

4
@fmpwizard Строка sbt 0.12 еще не выпущена ... Прекратите распространять FUD.
paradigmatic

3
Дело не в том, что sbt невозможно использовать, наша команда им пользуется. Но мой комментарий состоял в том, чтобы поддержать этот ответ, в котором говорилось: «... Но sbt страдает от серьезных несовместимых изменений между версиями, что затрудняет поиск правильного рабочего плагина для задачи и заставить его работать ...» Как вы заметили , Я не могу просто использовать плагин scct, мне пришлось его модифицировать (да, небольшое изменение, но потом мне пришлось его где-то опубликовать, чтобы вся моя команда могла получить к нему доступ) Боль без уважительной причины.
fmpwizard

3
Можете ли вы выполнять кросс-компиляцию для разных версий Scala с помощью gradle?
Machisuji

4

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


-11

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

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

1
Gradle основан на Groovy, который не является статически типизированным языком.
Vistritium

Gradle выполняет управление зависимостями между задачами, создать задачу максимально просто, я понятия не имею, как может быть проще написать плагин, чем для gradle, который может принимать Groovy, Java, плагины gradle и, возможно, многое другое.
Johnride
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.