В статье написано что в гредле это такое же дно как и в сбт, #янисагласен

укажите на место в gradle что имеется в виду под многомодульными проектами. И как организован layout на 120 модулей

А чем оно днище в сбт?

как сотни модулей будут описываться в sbt?

Смотря какие модули

Если это однотипные, то что-типа val myMicroSercice = project.in(file("my-microservice")).settings(libraryDependencies +=... ).dependsOn(common, utils)

Есть что-то сильно отдельное, то можно его в отдельной папке держать, а из других проектов на него ссылаться как val externalProject = ProjectRef("../external")

Сбт проверит что граф зависимостей ацикличен

в gradle мультимодули удобнее, чем в sbt. Не надо дублировать зависимости в виде .settings(libraryDependencies +=... ).dependsOn(common, utils) для каждого модуля. Просто в аггрегирующем модуле можно указывать переопределения зависимостей и заставлять вместо скачивания артефакта смотреть в определенную директорию с исходным кодом

в gradle мультимодули удобнее, чем в sbt. Не надо дублировать зависимости в виде .settings(libraryDependencies +=... ).dependsOn(common, utils) для каждого модуля. Просто в аггрегирующем модуле можно указывать переопределения зависимостей и заставлять вместо скачивания артефакта смотреть в определенную директорию с исходным кодом

в sbt Тоже не надо

Тоже необязательно, я в качестве примера показал просто

Ок, у меня есть проект из нескольких модулей. A, B, C. пусть C зависит от B, B от A Я хочу работать с кодом таким образом, чтобы мне при изменениях не приходилось собирать и пушить куда-либо артефакты. В тоже самое время, я хочу, чтобы у меня A, B, C собирались по отдельности в отдельные jar-ки. Соотв., в build.sbt проекта C у меня указана зависимость libraryDependencies += B, для B - libraryDependencies += A В аггрегирующем проекте я указываю, B как .dependsOn(A), C как .dependsOn(A, B). Когда появляется еще модуль - для него тоже приходится прописывать зависимости в .depends, чтобы можно было не пересобирать артефакты

А есть где-то примеры, как кодогенерацию в штанах делать?

В gradle же можно глобально переопределить резолвинг зависимостей для всех проектов. Что com.megacompany.A всегда вытаскивать из директории A для всех проектов. В sbt так тоже разве можно?

В gradle же можно глобально переопределить резолвинг зависимостей для всех проектов. Что com.megacompany.A всегда вытаскивать из директории A для всех проектов. В sbt так тоже разве можно?

Можно чуть подробнее? привычнее говорить о зависимостях с артефактами и репозиториями, а не пакетами и директориями

ОК, попробую у меня есть проект super-project. Пусть зависит от проектов utils, который в свою очередь зависит от commons. Каждый из проектов собирается в отдельный jar-файл. Соотв, у меня в каждом проекте лежит build.sbt, в котором описаны зависимости, например $ cat super-project/build.sbt libraryDependencies += "utils:1+" $ cat utils/build.sbt libraryDependencies += "commons:1+" Я хочу вести разработку всего проекта так, чтобы после изменения в любом из компонент мне не приходилось пушить utils.jar и commons.jar ни в какой-нибудь корпоративный репозиторий, ни даже в мой собственный локальный. Значит, что мне надо прописать зависимости от директорий с исходным кодом. Чтобы проект utils для удовлетворения своей зависимости в commons не пытался выкачать jar-файл с utils, а пошел в директорию с исходным кодом utils, которая есть у меня на компьютере, и выкачал ее. Для этого в sbt есть инструкция dependsOn. Соотв., я могу создать корневой проект root/ super-project/ utils/ commons/ в build.sbt корневого проекта я прописываю, что проект utils у меня лежит в директории utils, проект commons - в директории commons, проект super-project - в директории super-project. там же я с помощью superproject... .dependsOn(utils, commons) указываю, что super-project у меня зависит от исходников, лежащих в utils и commons, что utils ... .dependsOn(commons). Это позволяет мне не помещать информацию о моих разработческих хотелках по поводу разработки большого проекта super-project в меньшие проекты utils и commons. Позволяет даже отселить utils, commons и сам super-project в отдельные гит-сабмодули, которые не имеют между собой зависимостей на уровне исходного кода, а зависят только от собранных jar-файлов. Соотв., мой root-project в этом случае является только проектом аггрегатором, каждый из модулей можно девелопить отдельно, заботясь об обратной совместимости (конечно, возникают и проблемы у такого подхода, но речь не об этом). Речь о том, что если моему super-project нужен еще один модуль another-module, которому в свою очередь требуется util, то я для него тоже должен прописать в build.sbt корневого проекта зависимости. another-module... .dependsOn(utils, common), super-project... .dependsOn(another-module, ...) По сути - это каждый раз дублирование зависимостей, которые и так указаны в build.sbt каждого проекта в виде libraryDependencies += "utils:1+"

В gradle же нет необходимости делать так. В корневом проекте можно просто написать переопределение резолвинга зависимостей и сказать, что когда любому из сабпроектов понадобится библиотека "utils:1+", то надо просто собирать ее из исходников в директории utils.

Еще раз подчеркну, что это для того, чтобы не пушить jar-артефакты именно в процессе разработки, но при этом оставить каждый из проектов, кроме корневого девелоперского, в неведении относительно нашего хитроумного процесса разработки. Каждый из меньших проектов, собираемый сам по себе , совершенно не заботится о том, где лежат исходники требуемых библиотек. Ему нужны jar-файлы, описанные в его build.sbt в случае SBT. Все переопределения, нужные девелоперам для комфортной разработки на локальной машине, описываются только в одном месте - в корневом проекте, который в свою очередь предназначен только для разработки и не собирается в какой-либо артефакт

Именно поэтому я не стал отвечать)) слишком длинная история)

https://docs.gradle.org/current/userguide/multi_project_builds.html

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

Отказали, сказали контролировать не могут

https://github.com/dbdahl/rscala

https://github.com/dbdahl/rscala

ужс

В gradle же нет необходимости делать так. В корневом проекте можно просто написать переопределение резолвинга зависимостей и сказать, что когда любому из сабпроектов понадобится библиотека "utils:1+", то надо просто собирать ее из исходников в директории utils.

Ясно. Очень интересно. Хотя, если бы у меня было много повторяющегося кода, бы просто определил функцию в sbt или где-то в project/ Но откровенно признаюсь, не сталкивался с проектами > 10 модулей

Ясно. Очень интересно. Хотя, если бы у меня было много повторяющегося кода, бы просто определил функцию в sbt или где-то в project/ Но откровенно признаюсь, не сталкивался с проектами > 10 модулей

у меня такой. Ощутимо больше 10.

ну так чем пользуетесь, как организовали проекты?

у меня такой. Ощутимо больше 10.

а система сборки какая?

а система сборки какая?

давай так. Я отвечаю, а ты не начинаешь критиковать? :)

давай так. Я отвечаю, а ты не начинаешь критиковать? :)

давай

Мавен.

И как оно?

Сорри, но что плохого в Maven до момента, когда нужны его специфические фичи и не нужны фичи sbt?

во, как раз про сборщики трут. вопрос - есть проект с плагином sbt-scoverage. Как сделать так, чтобы я мог одной командой делать clean build, собрать дистрибутив, и при этом у меня и coverage отработал? Если собирать как советуют на офф сайте - sbt clean coverage test, то при добававлении к этой команде dist в продакшен дистрибутив попадает инструментированный код.

мавен днище

сбт пушка

и только пушкой можно пробить днище...

@ScalaDev Заметь, я молчу

мавен для тех кому нравится хмл писать (в этом ничего плохого нет).

@ScalaDev Заметь, я молчу

У нас мешанина языков, часть кода генерируемая... Мавен справляется.

У нас мешанина языков, часть кода генерируемая... Мавен справляется.

ну тут тогда наверное ant был бы проще :)

Есть мысль перейти на гредле, он тоже обещал справиться. СБТ не пройдет, много java-стов

по-моему все четыре норм с мешаниной языков и генерацией кода

ну тут тогда наверное ant был бы проще :)

Ок

Но я всё ещё хочу узнать, как генерить код для pants

Не знаю, у нас его нет. У нас есть зоопарк и собирается не только собственно код, но и что-то вроде ресурсных и миграционных ьандлов и черти что ещё.

ну тут тогда наверное ant был бы проще :)

Make)

Make)

bash

bash

Надо было в первоначальное ТЗ вставить "и не ерничать" :) Мавен справляется. У него многословный xml, есть пара странностей с кэшем, но он всегда работает. В планах gradle. Make и bash, конечно, занятные опции, но не сегодня.

sbt опасаюсь.

У них случился, кстати, релиз, или все еще бета?

Меик ? Не сегодня?))) ты че в 22 веке живёшь?)

Случился. 1.0.1 с ума сойти

А доки к плагинам как были говёные, так и остались

Меик ? Не сегодня?))) ты че в 22 веке живёшь?)

пока не знаю, сейчас до кофе доберусь, отвечу : )

сбт пушка

Да градл тоже вполне себе пулемёт :)))

Добрый день, я так понимаю, что дебажить future, то есть, узнать что лежит в нем, без грязных хаков, аля map по нему, не получится?

Точку останова поставь внутри футура

мап это хак!

ХА!

мап это хак!

А ты че не знал? Нужно везде Await юзать

Добрый день, я так понимаю, что дебажить future, то есть, узнать что лежит в нем, без грязных хаков, аля map по нему, не получится?

map не есть грязный хак (

foreach

Не такой грязный как map

Добрый день, я так понимаю, что дебажить future, то есть, узнать что лежит в нем, без грязных хаков, аля map по нему, не получится?

Разве что-то мешает поставить брекпоинт внутри Future?

Разве что-то мешает поставить брекпоинт внутри Future?

А что значит внутри Future?

Вот есть метод, который future возвращает

Это если ДЕБАЖИТЬ future

Вот есть метод, который future возвращает

Тогда, очевидно, нужно ждать результата выполнения - map/for each/onComplete

Понял, спасибо

andThen может быть полезен для всякого вида логирования

Хотя, если в при дебаге сделать suspend thread основного треда, то получится ли дождаться исполнения future в дебаггере?

Да, работает

А может кто видел реализацию Monad Open для Скалы?

https://github.com/thricejamie/sbt-meow

кажется я вызвал сатану

напомнило)) https://youtu.be/cpOIyGeS4H4

у меня кстати тоже никогда не получалось эти картинки увидеть :)

Scalalaz #28 - с Виктором Тараненко http://scalalaz.ru/series-28.html

Юху!

о Виктор классный

Ждемс player.fm

Блин, я ещё с Мариной не послушал, и ещё 24 предыдущих

Блин, я ещё с Мариной не послушал, и ещё 24 предыдущих

пора тебе саому просвещать народ

пора тебе саому просвещать народ

+1

Так, вечер, все уже не на работе, повторю вопрос: есть проект с плагином sbt-scoverage. Как сделать так, чтобы я мог одной командой делать clean build, т.е. собрать дистрибутив, и при этом у меня и coverage отработал? Если собирать как советуют на офф сайте - sbt clean coverage test, то при добававлении к этой команде dist в продакшен дистрибутив попадает инструментированный код.

А Олег ж уже был в эфире у рп

пора тебе саому просвещать народ

лучше мастеркласс а не подкаст