Если вы следите за этим блогом, то помните, что в последнее время я пишу (и говорю) о CDI (Contexts and Dependency Injection). У CDI много аспектов, но до сих пор я акцентировал внимание на том, как начать работу с CDI в вашем окружении и как интегрировать CDI в существующее Java EE 6 приложение, а затем сфокусировался на внедрении зависимостей в CDI. Это уже третий пост про внедрение в CDI: в первом я рассказывал о внедрении по умолчанию и спецификаторах, во второй о всех возможных точках внедрения (поле, конструктор, сеттер). В этом посте я расскажу о продюсерах или "как вы можете типобезопасным способом внедрять что угодно и куда угодно".

Это второй пост о внедрении зависимостей в CDI (Часть 1) после нашего разговора о том, как начать работу с CDI в вашем окружении и как интегрировать CDI в существующее Java EE 6 приложение. В этом посте я хочу рассказать о различных точках внедрения в CDI: поле, конструктор и сеттер. Для этого я буду использовать часть предыдущего примера: внедрение POJO генератора ISBN в сервлет.

После статьи о том, как начать работу с CDI в вашем окружении и нескольких советов о том, как интегрировать CDI в существующее Java EE 6 приложение, я хочу поговорить о внедрении зависимостей. Да, о простом внедрении или о том, как провести внедрение одного бина в другой. Из этой серии трех статей (Часть 2, Часть 3) вы увидите, что есть множество различных способов: давайте начнем с самого простого — обыкновенного внедрения.

Немного истории

В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.

С этого момента описанная модель ветвления GitFlow, начинает, что называется, расходиться по миру. Её берут на вооружение многие команды. Авторы пишут много статей об успешном её использовании. Она получает поддержку в большинстве инструментов, которые используют разработчики:

• Плагин к самому Git'у
• Плагины к различным IDE: IDEA, Eclipse
• Встроенная поддержка в GUI клиентах: SourceTree и Git Extensions
• Плагины для систем сборки: Maven, Gradle, и т.д.
• Встроенная поддержка в менеджерах репозиториев: GitHub, BitBucket, GitLab и т.д.

Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.