Какая самая лучшая система сборки Scala?

Я видел вопросы о IDE здесь - Какая из лучших IDE для разработки Scala? и Что это текущее состояние инструментария для Scala?, но у меня были смешанные впечатления от IDE. Прямо сейчас я использую Eclipse IDE с опцией автоматического обновления рабочего пространства, а KDE 4 Kate - как текстовый редактор. Вот некоторые из проблем, которые я хотел бы решить:

  • использовать мой собственный редактор. IDE действительно ориентированы на всех, используя их компоненты. Мне нравится Кейт лучше, но система обновления очень раздражает (она не использует inotify, а может быть, 10 секундный интервал опроса). Причина, по которой я не использую встроенный текстовый редактор, состоит в том, что сломанные автоматически завершенные функции заставляют IDE зависать, возможно, за 10 секунд.
  • перестроить только измененные файлы. Система сборки Eclipse нарушена. Он не знает, когда нужно перестраивать классы. Я почти половину времени собираюсь проектировать → чистить. Хуже того, кажется, что даже после того, как он завершил строительство моего проекта, через несколько минут он появится с какой-то странной ошибкой (отредактируйте - эти ошибки выглядят как вещи, которые ранее были решены с помощью проектa > чистые, но затем вернулись...). Наконец, установка "Предпочтения/Продолжение запуска, если проект содержит ошибки" для "подсказки", похоже, не влияет на проекты Scala (т.е. Он всегда запускается, даже если есть ошибки).
  • создать настройку. Я могу использовать "ночную" версию, но я хочу изменить и использовать собственные сборки Scala, а не компилятор, встроенный в плагин IDE. Было бы неплохо передать [например.] -Xprint:jvm компилятору (чтобы распечатать сниженный код).
  • быстрая компиляция Несмотря на то, что Eclipse не всегда правильно строится, он кажется быстрым - даже больше, чем fsc.

Я посмотрел на Ant и Maven, хотя еще не наработал (мне также нужно будет потратить время на решение № 3 и № 4). Я хотел посмотреть, есть ли у кого-нибудь другие предложения, прежде чем я потрачу время на то, чтобы работать с субоптимальной системой сборки. Спасибо заранее!

UPDATE. Теперь я использую Maven, передавая проект как плагин для компилятора. Это кажется достаточно быстрым; Я не уверен, что такое кеш-кеппинг Maven. Доступен текущий репозиторий для Scala 2.8.0 [ссылка]. Архетипы очень крутые, и кросс-платформенная поддержка кажется очень хорошей. Однако о проблемах с компиляцией я не уверен, что fsc на самом деле исправлена, или мой проект достаточно стабилен (например, имена классов не меняются) - запуск его вручную не мешает мне. Если вы хотите увидеть пример, не стесняйтесь просматривать файлы pom.xml, я использую [github].

ОБНОВЛЕНИЕ 2 - из тестов, которые я видел, Дэниел Спивак прав, что buildr быстрее, чем Maven (и, если кто-то делает инкрементные изменения, Maven 10 секундная латентность раздражает), поэтому, если один может создать совместимый файл сборки, тогда он, вероятно, стоит того...

ОТВЕТЫ

Ответ 1

Точки 2 и 4 чрезвычайно сложны в управлении с текущим скаляром. Проблема в том, что компилятор Scala немного тупой о создании файлов. В принципе, он будет создавать все, что вы его кормите, независимо от того, действительно ли этот файл нужно построить. Scala 2.8.0 будет иметь некоторые потрясающие улучшения в этом отношении, но до тех пор... Eclipse SDT действительно имеет очень сложный (и очень хакерский) код для отслеживания изменений и отслеживания зависимостей. В целом, это приличная работа, но, как вы видели, есть морщины. Eclipse SDT 2.8.0 будет полагаться на вышеупомянутые улучшения самого скаляса.

Таким образом, создание только модифицированных файлов практически не может быть и речи. Помимо SDT, единственным инструментом, о котором я знаю, даже пытается это, является SBT (Simple Build Tool). Он использует плагин компилятора для отслеживания файлов по мере их компиляции и запроса графика зависимости, вычисленного самим компилятором. На практике это дает примерно 50% -ное улучшение по сравнению с методом перекомпиляции. Еще раз, это хак, чтобы обойти недостатки в сканировании до 2.8.0.

Хорошей новостью является то, что достаточно быстрая компиляция по-прежнему возможна, даже не беспокоясь об обнаружении изменений. FSC использует ту же технологию (ох, которая звучит так "Charlie Eppes" ), которую Eclipse SDT использует для быстрой инкрементной компиляции. Короче говоря, это довольно быстро.

Лично я использую Apache Buildr. Его конфигурация значительно чище, чем Maven или SBT, а время запуска на порядок меньше (при работе под MRI). Он интегрируется с FSC и пытается самостоятельно определить некоторые основные изменения (довольно примитивные). Он также имеет автомагическую поддержку основных тестовых фреймворков Scala (ScalaTest, ScalaCheck и Specs), а также поддерживает совместную компиляцию с источниками Java и генерации метаданных IDE для IntelliJ и Eclipse. О, и он поддерживает все функции Maven (разрешение зависимостей и т.д.), А затем некоторые. Я даже работаю над расширением, которое позволит интерактивную поддержку оболочки, интегрированную с JavaRebel, и поддержку нескольких поставщиков оболочки (Scala, JIRB, Clojure REPL и т.д.). Он еще не готов к SVN, но я буду совершать, как только он будет готов (возможно, в срок для 1.3.5).

Как вы можете видеть, я твердо придерживаюсь мнения, что Buildr - лучший инструмент для сборки Scala. Его документация немного пятнистая, где Scala, но это потому, что все так просто, что трудно документировать, не чувствуя подробностей. Вы всегда можете проверить один из мои репозитории GitHub для примера. Удачи!

Ответ 2

Вы посмотрели Intellij IDEA и Scala интеграция? У Intellij есть лояльные (фанатичные?), Следующие среди разработчиков Java, поэтому вы можете найти, что это подходит для ваших нужд.

Ответ 3

Am также весьма расстроен с помощью плагина scala на Eclipse, и я могу добавить еще несколько проблем в список:

  • автозаполнение работает только некоторое время
  • отладчик работает неправильно (особенно при попытке отладки scala xml)
  • отладчик забывает о контрольных точках
  • "перейти к определению" не работает чаще, чем нет.

Я рад слышать, что Buildr звучит как лучшая альтернатива (на фронте сборки так или иначе), я дам вам попробовать - спасибо!

Ответ 4

По причинам полноты, я должен сказать, что есть также Pants - инструмент построения, который используется в Twitter ( один из ранних scala усыновителей)

Основное отличие в том, что оно предназначено не только для scala (и написано на python, кстати) и смоделировано после google build system.

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

Если вы боитесь SBT, может быть, еще один не очень популярный инструмент сборки, ABT, может быть альтернативой для вас?

Ответ 5

Я пошел по той же дороге, и вот где я нахожусь: После некоторого начального расследования я бросил Кейт. Я люблю использовать его для большинства вещей, но когда дело доходило до таких вещей, как определение завершения вкладок, мне было очень не хватает. Я бы порекомендовал вам вместо этого взглянуть на gedit, который гораздо более прочен для разработки Scala - С gedit в качестве моего редактора я использую SBT и нашел, что это отличный инструмент построения. Я могу перевести его в "тестовый" режим, когда при изменении любого кода он перекомпилирует соответствующие файлы и запускает мой тестовый набор. Это был чрезвычайно эффективный способ работы.

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

Ответ 6

Если вы используете Emacs, я думаю, что Ensime - довольно хорошая IDE. Я думаю, на момент написания, Ensime - единственная среда IDE, которая даст вам быструю и точную автозаполнение на обоих объектах Scala и Java, включая неявные преобразования.

Поддержка просмотра кода с помощью Speedbar, шаблонов кода с использованием превосходного Yasnippet и меню завершения кода с использованием Autocomplete. Это все очень современные, активно поддерживаемые пакеты Emacs. Там также можно добавить инкрементную поддержку здания для Maven и SBT.

Там гораздо больше возможностей, таких как интерактивная отладка, рефакторинг и интерпретатор Scala в более низком процессе. Все, что вы хотите в современной среде IDE для Scala, уже существует в Ensime. Очень рекомендуется для Emacsens.

Ответ 7

Если вы хотите использовать Eclipse, но создайте проект с помощью sbt и сможете отлаживать его, посмотрите здесь:

zikaprog.wordpress.com/2010/04/19/scala -eclipse-SBT-и-отладки/

Он также может применяться к строителям, отличным от sbt.