не в структуру самого проекта (git-репа), а в отдельный каталог? (например /opt/sbt-cache/staging/...)
В SBT_OPTS указываю параметр -Dsbt.global.staging, но дело в том что этот параметр игнорируется до тех пор, пока есть доступ на запись в каталог с репой. Если я например подключаю git-репу только как read-only, тогда sbt использует эту опцию (sbt.global.staging).
При этом другие опции (для ivy, coursier, boot) используются правильно (вне зависимости от прав на запись)
Мне нужно сложить все собранные файлы чтобы сделать образ-артефакт, в котром я смогу запустить sbt test без необходимости перекомпиляции исходников.
есть такй плагин sbt-out-of-tree но он для старого сбт (легко поправить под 1.х) и с кросспроектами не умеет
Вообще простейший способ - publishLocal и отдельный проект с тестами, который зависит от основного как от библиотеки.
и в таком случае при выполнении sbt test он не полезет в зависимости основного проекта и не начнёт повторную компиляцию основного проекта заново? Пока у меня проблема в том что я делаю sbt compile и sbt test:compile в одном месте (в одном контейнере), а sbt test и дальнейший sbt assembly мне нужно сделать в другом месте (в другом контейнере, которому будут "подложен" sbt-cache/ со всеми бинарными файлами созданными на этапе compile)
В таком случае sbt вообще не знает, что основной проект и проект с тестами хоть как-то связаны
но при этом компилируются оба проекта (основной и тест) сразу или тест будет компилироваться только при самом sbt test?
Он "подкладывается" копированием или монтированием? Если копированием, то там атрибуты файлов (например даты) не меняются? Инкрементальная компиляция, насколько помню, не на основе хеша файла, а на основе даты последнего изменения.
первоначально было через монтирование, откуда проблема и полезла. Т.е. git-репа была общая для первого этапа (compile) и для второго этапа (test+assembly). Я так и не понял до конца что именно "увидел" sbt тест в структуре репы (она была локально склонирована и содержимое в ней не менялось, за исключением созданных target/....), но в режиме sbt --debug --verbose было указано [debug] Recompiling all sources: number of invalidated sources > 50.0% of all sources и начинался процесс повторной сборки
в последних сбт что-то делали с датами файлов вроде, чтоб получать каждый раз одинаковые бинари на выходе
хотите "прикол"? cd project sbt compile (компиляция успешно проходит, повторный запуск sbt compile не перекомпилирует заново проект) cd .. cp -a project/ project2/ cd project2 sbt compile И оно заново ВСЁ перекомпилирует! Почему? Просто потому что имя каталога с проектом изменилось? (project -> project2). Возвращаюсь опять в project/, далее sbt compile - и опять не требуется перекомпиляция
даже переименование собственного каталога в котором расположен проект приводит к его перекомпиляции
Вполне вероятно: имя проекта берется из имени каталога и затем уже переопределяется в проекте (или не переопределяется при желании), так что имя каталога важно
а как переопределить имя проекта таким образом, чтобы имя каталога с репой проекта могло иметь любое название и процесс компиляции не зависел от этого (от имени каталога)?
thisProject id все еще висит имя папки, так что не факт, что поможет.
а имя хоста может иметь аналогичную ососбенность? Я переношу папки с проектом на другой хост (отличие только в имени хоста, в остальном полная копия каталога и путей) - и опять идёт перекомпиляция
а его сменить возможно?
отзыв. после апгрейда до 1.4.0RC2 проблема с перекомпиляцией при изменении имени каталога репы ушла, а также проект больше не перекомпилируется при запуске в новом контейнере @odomontois
Просто обновили?
только обновил. Новую фишку в возможности сложить все .class в jar и положить в отдельное место пока не проверил.
Обсуждают сегодня