сравнивая sbt и Gradle

Question

сравнивая sbt и Gradle

100

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

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

Hans Westerbeek 16 июнь 2012, в 09:25

Источник

0

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

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

спасибо всем ... Прочитав ваши идеи, я буду придерживаться Gradle. Мне кажется, что именно в этом направлении будут предприняты основные усилия по созданию инструментов для пространства JVM, когда мы оставим Maven позади.
Hans Westerbeek 17 июнь 2012, в 10:48
0

чтобы написать новую задачу sbt: [введите описание ссылки здесь] [1] [1]: stackoverflow.com/questions/9702863/…
vishal 31 янв. 2014, в 07:55
10

Раздражает, что этот вопрос здесь помечается как «основанный на мнении», вероятно, людьми, которые не работают в JVM-пространстве все время (и, следовательно, не имеют надзора). Ответы, приведенные ниже, являются фактическими и лишены священного воинства.
Hans Westerbeek 15 дек. 2015, в 11:00
0

Извините, но, например, этот ответ и тот, который выглядит точно так же, как основанные на мнении. И этот пользователь , согласно его профилю, имеет опыт работы с scala и sbt .
Tsyvarev 15 дек. 2015, в 11:43
4

Нет, эти ответы - это в первую очередь утверждения проверяемых фактов, а не мнения. Хотя этот вопрос может привлечь бесполезные ответы, на самом деле это не так. Он должен оставаться открытым как полезное описание реальных различий между инструментами.
erickson 21 апр. 2016, в 15:52

Показать ещё 5 комментариев

Теги:

scala

gradle

sbt

5 ответов

47

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

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

Недостатки:

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

paradigmatic 16 июнь 2012, в 15:58

0

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

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

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

Да, тестовый прогон параллелен по умолчанию (хотя вы можете сделать его последовательным, если это необходимо). Я также согласен, что Gradle кажется более зрелым и полированным, чем SBT.
paradigmatic 17 июнь 2012, в 13:38
25

+1 за недостаток «иероглифического синтаксиса». Это моя самая большая претензия к SBT. Перегрузка оператора всегда приводит к злоупотреблениям: - /
Ron Dahlgren 17 апр. 2013, в 23:03
7

Загадочный синтаксис SBT выявляет худшее в scala. Gradle основан на хорошо продуманной модели предметной области и прямом синтаксисе.
nemoo 24 май 2013, в 13:57
0

Тем временем быстрый SBT, инкрементный компилятор был извлечен в отдельную библиотеку (цинк) и может фактически использоваться плагином gradle для scala.
Machisuji 28 июль 2014, в 08:58

Показать ещё 5 комментариев

34

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

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

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

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

Jens Schauder 16 июнь 2012, в 10:46

2

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

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

@fmpwizard Строка sbt 0.12 еще не выпущена ... Прекратите распространять FUD.
paradigmatic 16 июнь 2012, в 14:04
0

ОК, вот еще один пример. github.com/dvc94ch/sbt-scct . На работе мы использовали этот плагин, и, как говорится в readme, он работает только с sbt 0.10.1. чтобы иметь возможность использовать sbt 0.11.2, нам пришлось пойти и использовать другой форк, который публикует другой человек, который является сборкой для sbt 0.11.2. Это не ФУД.
fmpwizard 17 июнь 2012, в 03:23
1

@fmpwizard Я не совсем уверен, но похоже, что ваша проблема имеет действительно простое решение, аналогичное этому: github.com/ivmaykov/sbt-scct/commit/… Исправьте меня, если я ошибаюсь
om-nom-nom 17 июнь 2012, в 12:03
3

Это не sbt невозможно использовать, наша команда использует его. Но мой комментарий состоял в том, чтобы поддержать этот ответ, который гласил: «... Но sbt страдает от серьезных несовместимых изменений между версиями, что затрудняет поиск правильного рабочего плагина для задачи и заставить его работать ...» Как вы заметили Я не могу просто использовать плагин scct, я должен был изменить его (да, небольшое изменение, но затем я должен был опубликовать его где-нибудь, чтобы вся моя команда могла получить к нему доступ). Боль без веской причины.
fmpwizard 18 июнь 2012, в 22:53
0

Я сам тоже страдал от этого. Я действительно не знаю, почему в 0.13 они изменили структуру дома sbt, чтобы заставить меня страдать, это действительно необходимо?
zinking 10 апр. 2014, в 02:30
3

Вы можете сделать кросс-компиляцию для разных версий Scala, используя gradle?
Machisuji 28 июль 2014, в 08:59
0

использование СБТ в течение 2 лет; 0.13 было хорошо. В целом я доволен этим. DSL очень хорош, и, несмотря на все жалобы на перегрузку операторов ... он довольно последовательн в использовании. Я уверен, что есть некоторые замечательные аспекты, которые многие не оценят, например, тот факт, что DSL генерирует декларативные неизменные структуры данных, которые информируют процесс сборки.
Tim Harper 02 авг. 2015, в 18:44

Показать ещё 7 комментариев

3

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

eugenevd 27 янв. 2015, в 17:12

-7

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

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

Saby 08 дек. 2015, в 07:21

0

Gradle основан на Groovy, который не является статически типизированным языком.
Vistritium 15 март 2016, в 14:39
0

Gradle управляет зависимостями между задачами, создать задачу как можно проще, я понятия не имею, как проще написать плагин, чем для gradle, который может использовать Groovy, Java, плагины gradle и, возможно, больше.
Johnride 21 март 2016, в 18:28

Ещё вопросы

SBT в каком-то смысле похож на Vim: если вы ухватитесь за него, вы будете довольны. И, кстати, есть также maven и lein (был создан для clojure, но работает и со scala).
Не испытывайте давления, чтобы перейти к SBT. Некоторые известные члены сообщества Scala используют Gradle. Вместо этого используйте SBT в качестве эксперимента, зная, что вместо этого вы можете использовать Gradle.
спасибо всем ... Прочитав ваши идеи, я буду придерживаться Gradle. Мне кажется, что именно в этом направлении будут предприняты основные усилия по созданию инструментов для пространства JVM, когда мы оставим Maven позади.
чтобы написать новую задачу sbt: [введите описание ссылки здесь] [1] [1]: stackoverflow.com/questions/9702863/…
Раздражает, что этот вопрос здесь помечается как «основанный на мнении», вероятно, людьми, которые не работают в JVM-пространстве все время (и, следовательно, не имеют надзора). Ответы, приведенные ниже, являются фактическими и лишены священного воинства.
Извините, но, например, этот ответ и тот, который выглядит точно так же, как основанные на мнении. И этот пользователь , согласно его профилю, имеет опыт работы с scala и sbt .
Нет, эти ответы - это в первую очередь утверждения проверяемых фактов, а не мнения. Хотя этот вопрос может привлечь бесполезные ответы, на самом деле это не так. Он должен оставаться открытым как полезное описание реальных различий между инструментами.
Правильно ли я понимаю, что была / была необходимость в функции кросс-компиляции / публикации из-за проблем, которые были у Scala с обратной двоичной несовместимостью?
Да. И эти проблемы могут повториться при переходе на Scala 2.10.
Я бы добавил еще два отличия: * В SBT проще управлять зависимостями, IMO. * SBT тест бегун кажется быстрее; Я подозреваю, что здесь есть какой-то хитрый параллелизм, но я предполагаю. SBT кажется более способным, но менее зрелым продуктом.
Да, тестовый прогон параллелен по умолчанию (хотя вы можете сделать его последовательным, если это необходимо). Я также согласен, что Gradle кажется более зрелым и полированным, чем SBT.
+1 за недостаток «иероглифического синтаксиса». Это моя самая большая претензия к SBT. Перегрузка оператора всегда приводит к злоупотреблениям: - /
Загадочный синтаксис SBT выявляет худшее в scala. Gradle основан на хорошо продуманной модели предметной области и прямом синтаксисе.
Тем временем быстрый SBT, инкрементный компилятор был извлечен в отдельную библиотеку (цинк) и может фактически использоваться плагином gradle для scala.
Насколько я знаю, было только одно очень важное изменение: когда sbt переключился с 0.7.x на 0.1.x
Если вы используете плагин для sbt 0.11.2, а затем переходите к sbt 0.12, вам нужно подождать, пока автор плагина скомпилирует новую версию или сделает это самостоятельно. idea-sbt - один из примеров.
@fmpwizard Строка sbt 0.12 еще не выпущена ... Прекратите распространять FUD.
ОК, вот еще один пример. github.com/dvc94ch/sbt-scct . На работе мы использовали этот плагин, и, как говорится в readme, он работает только с sbt 0.10.1. чтобы иметь возможность использовать sbt 0.11.2, нам пришлось пойти и использовать другой форк, который публикует другой человек, который является сборкой для sbt 0.11.2. Это не ФУД.
@fmpwizard Я не совсем уверен, но похоже, что ваша проблема имеет действительно простое решение, аналогичное этому: github.com/ivmaykov/sbt-scct/commit/… Исправьте меня, если я ошибаюсь
Это не sbt невозможно использовать, наша команда использует его. Но мой комментарий состоял в том, чтобы поддержать этот ответ, который гласил: «... Но sbt страдает от серьезных несовместимых изменений между версиями, что затрудняет поиск правильного рабочего плагина для задачи и заставить его работать ...» Как вы заметили Я не могу просто использовать плагин scct, я должен был изменить его (да, небольшое изменение, но затем я должен был опубликовать его где-нибудь, чтобы вся моя команда могла получить к нему доступ). Боль без веской причины.
Я сам тоже страдал от этого. Я действительно не знаю, почему в 0.13 они изменили структуру дома sbt, чтобы заставить меня страдать, это действительно необходимо?
Вы можете сделать кросс-компиляцию для разных версий Scala, используя gradle?
использование СБТ в течение 2 лет; 0.13 было хорошо. В целом я доволен этим. DSL очень хорош, и, несмотря на все жалобы на перегрузку операторов ... он довольно последовательн в использовании. Я уверен, что есть некоторые замечательные аспекты, которые многие не оценят, например, тот факт, что DSL генерирует декларативные неизменные структуры данных, которые информируют процесс сборки.
Gradle основан на Groovy, который не является статически типизированным языком.
Gradle управляет зависимостями между задачами, создать задачу как можно проще, я понятия не имею, как проще написать плагин, чем для gradle, который может использовать Groovy, Java, плагины gradle и, возможно, больше.

VonC · Accepted Answer · 2012-06-16T17-48-00.000Z

Обратите внимание, что одним ключевым отличием между 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.

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

Самое большое неудобство, с которым я когда-либо сталкивался, это то, что sbt нельзя указывать для правила не перекомпилировать каждый раз, когда оно упоминается. Встроенные правила для Java и Scala имеют эту функцию, но она не доступна для написания пользовательских правил. Поэтому каждый раз, когда вы генерируете программный файл или документацию, и даже если вы генерируете jar-файл, ваша задача будет выполняться при каждом вызове, независимо от того, какие изменения в источниках были фактически выполнены. Даже Марка достаточно умна, но не sbt
@ayvango Это не относится к сегодняшним дням. Есть много плагинов, которые используют эту функцию, например, Android-SDK-плагин
Вы знаете, какой API используется для этой функциональности?
так что это то, чего не хватает плющу по сравнению с maven и gradle? Это странно