Плюсы и минусы использования sbt vs maven в проекте Scala

119

Какой инструмент построения лучше всего подходит для Scala? Каковы плюсы и минусы каждого из них? Как определить, какой из них использовать в проекте?

  • 5
    Я перешел с Maven на Gradle для проектов Scala из-за его превосходной поддержки многомодульных сборок. Опыт Твиттера с SBT описывается ими как «ослепляющая боль», и они пытаются отойти от него (с Maven в качестве остановки в этом процессе).
  • 21
    Еще один крутой закрытый вопрос ...
Показать ещё 2 комментария
Теги:
maven
sbt

2 ответа

68
Лучший ответ

Мы используем Maven для создания проектов Scala на работе, потому что он хорошо интегрируется с нашим CI-сервером. Мы могли бы просто запустить оболочку script, чтобы начать сборку, конечно же, но у нас есть куча другой информации, выходящей из Maven, которую мы хотим зайти в CI. Это единственная причина, по которой я могу думать о том, чтобы использовать Maven для проекта Scala.

В противном случае просто используйте SBT. Вы получаете доступ к тем же зависимостям (действительно лучшая часть о maven, IMHO). Вы также получаете инкрементную компиляцию, которая огромна. Возможность запуска оболочки внутри вашего проекта, что тоже отлично.

ScalaMock работает только с SBT, и вы, вероятно, захотите использовать это, а не для Java mocking library. Кроме того, гораздо проще расширить SBT, так как вы можете написать полный код Scala в файле сборки, так что вам не нужно проходить через все rigamarole написания Mojo.

Короче говоря, просто используйте SBT, если вам не нужна жесткая интеграция в ваш сервер CI.

Поделиться
  • 21
    Я не согласен ни с одним из вышеперечисленных, но просто хотел бы отметить, что я нахожусь в процессе написания ScalaMock 3 , одной из основных целей которого является облегчение поддержки других систем сборки.
  • 0
    Здорово, потому что я не уверен, что смогу использовать SBT на работе в ближайшее время. С нетерпением жду этого!
Показать ещё 5 комментариев
19

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

FWIW, в существует <... scala список рассылки.

Мои 2c: Go с sbt, если у вас нет конкретных требований

  • для простых проектов, он абсолютно без усилий (вам даже не нужен файл сборки до тех пор, пока вы не найдете зависимости)
  • он обычно используется в scala проектах с открытым исходным кодом. Вы можете легко узнать о конфигурации, заглянув в проекты других людей. Кроме того, многие проекты предполагают, что вы используете sbt и предоставляете готовые инструкции по копированию и вставке для добавления их в качестве зависимости от вашего проекта.
  • Если вы используете IntelliJ IDEA, он может быть полностью интегрирован. Вы можете использовать IDEA sbt для непрерывной компиляции вашего проекта, и наоборот, вы можете быстро использовать sbt генерировать проекты IDEA. Последнее чрезвычайно полезно, если вы находитесь в цикле "моментальных снимков", в зависимости от других ваших собственных библиотек, которые попадают из младшей версии в младшую, - просто закройте проект, обновите версию в файле сборки, повторно запустите gen-idea и повторно открыть проект: сделанные обновления.
  • готов к большинству задач, которые вам понадобятся (compile, test, run, doc, publish-local, console) - console - одна из лучших функций.
  • Некоторые люди выделяют функцию, которая может быть источником исходных репозиториев, непосредственно захваченных GitHub. Я не использовал это, поэтому не могу комментировать здесь.

Некоторые люди ненавидят sbt, потому что используют Ivy для управления зависимостями (я не могу прокомментировать ее плюсы и минусы, но большую часть времени это не проблема), некоторые люди ненавидят sbt, потому что вы указываете файл сборки в термины scala DSL вместо XML. Некоторые люди были разочарованы тем, что формат sbt изменился с v0.7 на v0.10, но, очевидно, миграция не повлияет на вас, если вы начнете с нуля.

Поделиться
  • 27
    Я ненавижу sbt, потому что он злоупотребляет символическими операторами и некоторыми глупыми решениями, такими как поддержка форматов определения .sbt и .scala, но помещает их в разные места, а операторы в .sbt должны быть отделены хотя бы пустой строкой и т. Д. Документы sbt улучшаются, но не достаточно хороши в данный момент. Больше всего мне не хватает некоторых полных (от минимального до реального комплекса) примеров файлов .sbt / .scala, объясняющих построчно, охватывающих все возможности sbt. Тем не менее, я использую sbt ежедневно, потому что Maven сосет намного больше.
  • 6
    Жаль, что этот вопрос был закрыт, я уверен, что есть и фактические различия: например, этот отрывок из книги Мэннинга о SBT: «Если есть зависимости между целями Maven (скажем, одна цель создает файл, который используется другим) тогда вы не можете распараллелить вашу сборку с Maven. С sbt вы должны указать явную зависимость между задачами. Это позволяет sbt запускать задачи параллельно BY DEFAULT. Если задача A зависит от B, а C также зависит от B, то sbt запускает задание B, а затем запускает A и C параллельно. " Надеюсь, что этот комментарий поможет некоторым читателям.
Показать ещё 3 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню