Я перешел с Maven на Gradle для проектов Scala из-за его превосходной поддержки многомодульных сборок. Опыт Twitter с SBT описывается ими как «ослепляющая боль», и они пытаются уйти от этого (с Maven в качестве временной остановки в этом процессе).
Ben Manes
26
Еще один крутой закрытый вопрос ...
Седрик Х.
15
Я вижу так много хороших вопросов, которые просто закрыты; Я не знаю, кто дает этим людям право произвольно решать закрывать вопрос или нет. Я даже не обращаю внимания на то, близки они или нет.
user1888243 05
2
Согласен. К счастью, у нас есть 2 ответа, прежде чем этот вопрос будет закрыт. Плохо для тех, кто голосует за закрытие этого вопроса ...
hqt
Ответы:
84
Мы используем Maven для создания проектов Scala на работе, потому что он хорошо интегрируется с нашим CI-сервером. Конечно, мы могли бы просто запустить сценарий оболочки, чтобы начать сборку, но у нас есть много другой информации, поступающей от Maven, которую мы хотим передать в CI. Это единственная причина, по которой я могу использовать Maven для проекта Scala.
В противном случае просто используйте SBT. Вы получаете доступ к одним и тем же зависимостям (действительно, лучшая часть maven, IMHO). Вы также получаете инкрементную компиляцию, которая огромна. Возможность запускать оболочку внутри вашего проекта, что тоже здорово.
ScalaMock работает только с SBT, и вы, вероятно, захотите использовать его, а не имитирующую библиотеку Java. Вдобавок ко всему, SBT намного проще расширить, так как вы можете написать полный код Scala в файле сборки, поэтому вам не нужно проходить через всю ритуал написания Mojo.
Короче говоря, просто используйте SBT, если вам действительно не нужна тесная интеграция с вашим CI-сервером.
Я не возражаю ни с одним из вышеперечисленных, но просто хотел указать, что я пишу ScalaMock 3 , одна из основных целей которого - упростить поддержку других систем сборки.
Пол Батчер
1
Для полноты картины стоит упомянуть, что ScalaMock 2 отлично работает с любой системой сборки (это просто баночка) до тех пор, пока вам не нужно использовать сгенерированные имитаторы (т.е. пока вам нужно только имитировать черты / интерфейсы. ).
Мои 2c: используйте 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, но очевидно, что миграция не повлияет на вас, если вы начнете с нуля.
Я ненавижу sbt, потому что он злоупотребляет символическими операторами и некоторыми глупыми решениями, например, оба поддерживают форматы определения .sbt и .scala, но помещают их в разные места, а операторы в .sbt должны быть разделены по крайней мере пустой строкой и т. Д. sbt улучшаются, но пока недостаточно хороши. Больше всего мне не хватает некоторых полных (от минимальных до реальных) примеров файлов .sbt / .scala, объясненных строка за строкой, охватывающих все возможности sbt. Тем не менее, я использую sbt ежедневно, потому что Maven отстой гораздо больше.
xiefei 01
6
Жаль, что этот вопрос был закрыт, я уверен, что есть и фактические различия: например, этот отрывок из книги Мэннинга о SBT: «Если есть зависимости между целями Maven (скажем, одна цель создает файл, который используется другой) то вы не можете распараллелить свою сборку с Maven. С sbt вы должны указать явную зависимость между задачами. Это позволяет sbt запускать задачи параллельно ПО УМОЛЧАНИЮ. Если задача A зависит от B, а C также зависит от B, тогда sbt запускает задачу B, а затем запускает A и C параллельно ». Надеюсь, этот комментарий поможет некоторым читателям.
jhegedus 02
20
Я нашел эту ветку очень полезной. Мне очень часто кажется, что модераторы Stackoverflow слишком охотно закрывают темы. Кого волнует, что они «не по теме», если они очень часто именно то, что ищут пользователи (и находят через поиск в Интернете). Как будто моды Stackoverflow намеренно пытаются воссоздать xkcd 979 .
Вилле
3
@Ville И мои мысли. Голосование против, редактирование и закрытие стало слишком агрессивным.
ankush981
2
Для всех, кто смотрит на это сейчас, жалобы @xiefei были рассмотрены. SBT отказался от многих дополнительных операторов / синтаксиса, и операторы в файлах / sbt больше не нуждаются в разделении пробелов.
Ответы:
Мы используем Maven для создания проектов Scala на работе, потому что он хорошо интегрируется с нашим CI-сервером. Конечно, мы могли бы просто запустить сценарий оболочки, чтобы начать сборку, но у нас есть много другой информации, поступающей от Maven, которую мы хотим передать в CI. Это единственная причина, по которой я могу использовать Maven для проекта Scala.
В противном случае просто используйте SBT. Вы получаете доступ к одним и тем же зависимостям (действительно, лучшая часть maven, IMHO). Вы также получаете инкрементную компиляцию, которая огромна. Возможность запускать оболочку внутри вашего проекта, что тоже здорово.
ScalaMock работает только с SBT, и вы, вероятно, захотите использовать его, а не имитирующую библиотеку Java. Вдобавок ко всему, SBT намного проще расширить, так как вы можете написать полный код Scala в файле сборки, поэтому вам не нужно проходить через всю ритуал написания Mojo.
Короче говоря, просто используйте SBT, если вам действительно не нужна тесная интеграция с вашим CI-сервером.
источник
Вопрос в опасности просто породить множество мнений; было бы лучше иметь четкий список требований или описание вашей среды, предыдущих знаний и т. д.
FWIW, в этой ветке списка рассылки scala есть больше мнений .
Мои 2c: используйте sbt, если у вас нет особых требований
gen-ideaзадача и повторно откройте проект: обновления выполнены.compile,test,run,doc,publish-local,console) - Вconsoleэто одна из лучших возможностей.Некоторые люди ненавидят sbt, потому что он использует Ivy для управления зависимостями (я не могу комментировать его плюсы и минусы, но в большинстве случаев это не проблема), некоторые люди ненавидят sbt, потому что вы указываете файл сборки с точки зрения Scala DSL вместо XML. Некоторые люди были разочарованы тем, что формат sbt изменился с v0.7 на v0.10, но очевидно, что миграция не повлияет на вас, если вы начнете с нуля.
источник