Comments 12
В начале, какая-то история про заказчика, потом helloworld идёт, которая делается до завтрака.
Единственная фишечка - какая-то гексагональная штука, про которую сказано гуглить. Которая даёт какие то геморрои, с которыми героически справляются потом.
Всегда интересовало, зачем вы тестите save(entity), get(энтити)Проверяете работает ли спринг жпа?
Идитe дальше, протести жаву! User =new User() ; assertFalse(user==null)
Всегда интересовало, зачем вы тестите save(entity), get(энтити)
Там же
как же я плюсую дико, я такой настроился, запасся минералочкой, думал, вдруг сейчас пойдет какая нибудь интересная статейка, где описывается кастомная логика деплоя артефактов, какие то хитрые собственные plugin extension, хитрые зависимости тасок и их workflow, а на деле оказался почти gradle-demo с оф сайта :(
Честео говоря, я в этой воде из хеллоу ворлда на spring и gradle, не нашел, где же та самая нетривиальная конфигурация.
На кого эта статья? Гайд для тех кто хочет поднять свой первый сервис на спринге? Ну так и пишете это в заголовке. Хотя лучше вообще не пишете, таких гайдов сотни
Или эта статья для тех кто хочет узнать новые тонкости гредла? Тогда минимум 95% явно не про тонкости и ее нужно почистить от воды
Так и не увидел нетривиальную конфигурацию на gradle. Но в любом случай, на gradle это еще +- можно оформить по человечески. Давайте лучше нетривиальную конфигурацию на maven. О Боже, как я люблю программировать на xml...
Если вам приходится программировать в билд конфигурациях, то у вас проблема вне зависимости от того, используете вы xml, gradle, kotlin или что-либо еще. Если у вас для билда нужна сложная логика, то её нужно вытаскивать в плагины к билд системы, а не пихать её в билд конфигурацию.
В этом плане использование xml в мавен даже полезно - ибо сложный xml конфиг достаточно быстро вызывает отторжение и желание с этим что-то сделать. А в каком-нибудь gradle люди начинают строчить билд логику на груви и осознают что что-то пошло не так сильно позже.
Можете пожалуйста развернуть мысль? Билд логика не должна быть в билд туле?
Или вы про то, что не нужно делать всё в одном файле? Даже если ваша кастомная билд логика на 2 строки?
Вот мой опыт с мейвеном прямо обратен. Вместо того, чтобы делать плагины и совмещать конфиг с логикой, люди пишут кастомные скрипты поверх (например на баше/питоне) или вообще в pipeline script закидывают эту логику. Потому что мейвеновые плагины тормозные и неудобные.
Можете пожалуйста развернуть мысль? Билд логика не должна быть в билд туле?
Билд логика должна быть в билд туле, а не в билд конфигурации. Например, если вам нужно скомпилировать ваш java проект, то в хорошей билд системе у вас будет декларативный конфиг для соответствующего плагина, а не скрипт вызывающий javac.
Или вы про то, что не нужно делать всё в одном файле? Даже если ваша кастомная билд логика на 2 строки?
Я про то, что билд конфиг должен быть декларативным, а не императивным. Императивные элементы должны быть вынесены в отдельные сущности, а не смешиваться с декларативными.
Вот мой опыт с мейвеном прямо обратен. Вместо того, чтобы делать плагины и совмещать конфиг с логикой, люди пишут кастомные скрипты поверх (например на баше/питоне) или вообще в pipeline script закидывают эту логику. Потому что мейвеновые плагины тормозные и неудобные.
Это потому что люди не хотят разбираться в инструментах которые используют. Ничто не запрещает прям в репу с проектом положить java сорцы плагина к мавену и тут же его использовать в pom.xml соседних модулей. Но люди почему-то предпочитают вхерачить какой-нибудь ant скрипт внутрь pom.xml, а потом плачутся, что злой мавен заставляет их на xml программировать. И это еще по-божески, я вот встречал ситуацию когда люди не осилили multi module мавен проекты и в итоге навелосипедили python скрипт, который в нужном порядке дергал mvn install -f для мавен модулей в репе.
При этом писали это вполне себе крутые разработчики на java. Почему-то, когда речь заходит о сборке, деплое и прочей инфраструктуре, у многих разработчиков напрочь выключаются навыки программирования и проектирования.
У мавена много серьезных недостатков, но "программирование на xml" это недостаток не мавена, а людей которые не умеют им пользоваться.
Маленькие таски отлично живут в билд-конфигурации, сложные - в buildSrc. Выносить функцию в три строчки(например с кастомной логикой генерации версии) в отдельный плагин или кодовую базу - вы еще тот извращенец.
Очевидным решением было бы добавить нужный атрибут и забыть про это недоразумение.
Очевидным решением является создание в приложении конфигурации, содержащей в себе все необходимые бины.
Однако для этого нам понадобится добавить в модуль business-core зависимость от spring-context, чего в ядре нашего приложения мы всеми силами стараемся избежать. Поэтому пойдём другим путём. Мы создадим ещё один модуль - common. И добавим зависимость ему.
Добавляем модулю business-core зависимость от common.
И в итоге ядро транзитивно зависит от spring-context. (facepalm)
Gradle и нетривиальная конфигурация