Size: a a a

Scala User Group

2020 January 14

Oℕ

Oleg ℕizhnik in Scala User Group
Это чтобы код с телефона писать?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Мне пока без авто норм
источник

AD

Apache DOG™ in Scala User Group
Oleg ℕizhnik
Это чтобы код с телефона писать?
да
источник

NV

Nikita Vilunov in Scala User Group
Друзья, помогите нормально разбить sbt-проект на подмодули. Есть некий модуль-либа lib, который используется в модулях-приложениях app1 и app2, подтягиваясь через dependsOn(lib). Есть так же lib-test, который содержит общий код, использующийся во всех тестах в приложениях, которые дергают lib, подтягивается через dependsOn(lib-test % Test). Есть варик слить обе либы в одну lib, положив код lib-test в папку test и подтягивать зависимость через dependsOn(lib % "compile->compile;test->test"). Вопрос один — почему так делать не стоит?
источник

NV

Nikita Vilunov in Scala User Group
Есть хороший аргумент за этот варик — у нас гарантированно не будет тестового кода в рантайм-джарке, потому что она просто не запустится, а с оригинальным вариком мы можем просто забыть % Test, и тестовый код будет во всех конфигурациях
источник

GP

Grigory Pomadchin in Scala User Group
Nikita Vilunov
Друзья, помогите нормально разбить sbt-проект на подмодули. Есть некий модуль-либа lib, который используется в модулях-приложениях app1 и app2, подтягиваясь через dependsOn(lib). Есть так же lib-test, который содержит общий код, использующийся во всех тестах в приложениях, которые дергают lib, подтягивается через dependsOn(lib-test % Test). Есть варик слить обе либы в одну lib, положив код lib-test в папку test и подтягивать зависимость через dependsOn(lib % "compile->compile;test->test"). Вопрос один — почему так делать не стоит?
Сливать только когда жизненный цикл библиотек сильно зависим; в остальных случаях только жизнь и проект усложнишь; если он паблишится отдельной джаркой, зачем отказываться от этих благ?)
источник

NV

Nikita Vilunov in Scala User Group
Grigory Pomadchin
Сливать только когда жизненный цикл библиотек сильно зависим; в остальных случаях только жизнь и проект усложнишь; если он паблишится отдельной джаркой, зачем отказываться от этих благ?)
Мб есть что-то более существенное? Усложнение жизни там будет минимальное, да и на паблишинг джарок нам пофиг, у нас вообще другие артефакты
источник

GP

Grigory Pomadchin in Scala User Group
Nikita Vilunov
Мб есть что-то более существенное? Усложнение жизни там будет минимальное, да и на паблишинг джарок нам пофиг, у нас вообще другие артефакты
Что значит более существенное? Видимо чего-то не хватает в твоём вопросе; что мешает тебе все сторонние зависимости в проект добавить кодом и зависеть от них?
источник

NV

Nikita Vilunov in Scala User Group
Grigory Pomadchin
Что значит более существенное? Видимо чего-то не хватает в твоём вопросе; что мешает тебе все сторонние зависимости в проект добавить кодом и зависеть от них?
Ну вот конкретно со сторонними зависимостями мешает например то, что я копирую кучу кода и нужно его поддерживать, а в этом случае я просто решаю как правильнее распихать свой собственный код по папкам
источник

GP

Grigory Pomadchin in Scala User Group
Nikita Vilunov
Ну вот конкретно со сторонними зависимостями мешает например то, что я копирую кучу кода и нужно его поддерживать, а в этом случае я просто решаю как правильнее распихать свой собственный код по папкам
А, я криво спросонья прочитал тогда
источник

GP

Grigory Pomadchin in Scala User Group
ты знаешь я пробовал и способом и первым и вторым; разницы никакой)
источник

GP

Grigory Pomadchin in Scala User Group
В случае когда тест не вынесен, и ты например захочешь тест в нескольких под проектах использовать, могут циклические зависимости возникнуть; но они решаемые
источник

GP

Grigory Pomadchin in Scala User Group
я все по максимуму схлопнул, что бы кучу тест проектов не иметь; всеравно их никто не использует кроме нас
источник

AO

Alexey Otts in Scala User Group
Nikita Vilunov
Друзья, помогите нормально разбить sbt-проект на подмодули. Есть некий модуль-либа lib, который используется в модулях-приложениях app1 и app2, подтягиваясь через dependsOn(lib). Есть так же lib-test, который содержит общий код, использующийся во всех тестах в приложениях, которые дергают lib, подтягивается через dependsOn(lib-test % Test). Есть варик слить обе либы в одну lib, положив код lib-test в папку test и подтягивать зависимость через dependsOn(lib % "compile->compile;test->test"). Вопрос один — почему так делать не стоит?
потому что в либе будут свои тесты, зачем их инклудить?
источник

NV

Nikita Vilunov in Scala User Group
Alexey Otts
потому что в либе будут свои тесты, зачем их инклудить?
Конкретно у нас либа максимально простая, тестировать там нечего, да и если бы были, то в чем проблема с инклюдами?
источник

GP

Grigory Pomadchin in Scala User Group
Alexey Otts
потому что в либе будут свои тесты, зачем их инклудить?
бывает что ты в проекте А в тестах реализовал матчеры и всякую такую фигню; в проекте Б ты их хочешь использовать в тестах
источник

AO

Alexey Otts in Scala User Group
Могу предположить, что эти тесты будут гоняться несколько раз, так как попадут в класс паз
источник

GP

Grigory Pomadchin in Scala User Group
Alexey Otts
Могу предположить, что эти тесты будут гоняться несколько раз, так как попадут в класс паз
Нет
источник

AO

Alexey Otts in Scala User Group
Grigory Pomadchin
бывает что ты в проекте А в тестах реализовал матчеры и всякую такую фигню; в проекте Б ты их хочешь использовать в тестах
берёшь и выносишь 🤷‍♂️
источник

GP

Grigory Pomadchin in Scala User Group
они как зависимость будут
источник