Maven: запустить внешний процесс, не блокируя вашу сборку

Давайте предположим, что мы должны выполнить кучу приемочных тестов с BDD-инфраструктурой, такой как Cucumber, как часть сборки Maven .

Использование Maven Failsafe Plugin не сложно. Но у него есть неявное требование : контейнер, в котором находится реализация, которую мы собираемся протестировать, должен быть уже запущен .

Многие контейнеры, такие как Jetty или JBoss, предоставляют свои собственные плагины Maven , чтобы позволить запускать сервер как часть работы Maven. И есть также хороший общий плагин Maven Cargo, который предлагает реализацию того же поведения для многих различных контейнеров.

Эти плагины позволяют, например, запускать сервер в начале задания Maven, развертывать реализацию, которую вы хотите протестировать, запускать тесты и останавливать сервер в конце.

Все механизмы, которые я описал, работают, и они обычно очень полезны для различных подходов к тестированию.

К сожалению, я не могу применить это решение, если мой контейнер не является поддерживаемым контейнером. Если не очевидно, я решил написать собственный плагин или добавить поддержку для моего конкретного контейнера в Maven Cargo.

В моем конкретном случае мне нужно было найти способ использовать JBoss Fuse от Red Hat, контейнер на базе Karaf .

Я решил постараться сохранить его легким и не писать полнофункциональный плагин Maven и в конечном итоге положиться на плагин GMaven , или как я недавно прочитал в интернете «Gradle для бедных» .

GMaven — это в основном плагин для добавления поддержки Groovy к вашей работе в Maven, позволяющий вам выполнять фрагменты Groovy как часть вашей работы . Мне это нравится, потому что это позволяет мне pom.xml скрипты прямо в pom.xml .

Он также позволяет вам определять ваш скрипт в отдельном файле и выполнять его, но это то же самое поведение, которого вы могли бы достичь с помощью простого Java и плагина Maven Exec ; решение, которое мне не очень нравится, потому что скрывает реализацию и усложняет представление о том, чего пытается достичь полная сборка.

Очевидно, что этот подход имеет смысл, если сценарий, который вы собираетесь написать, достаточно прост, чтобы быть автоописательным.

  Я опишу свое решение, начав с того, что поделюсь с вами своими пробами и ошибками и ссылками на различные статьи и посты, которые я нашел:

Сначала я решил использовать Maven Exec Plugin для непосредственного запуска моего контейнера. Что-то вроде того, что было предложено здесь http://stackoverflow.com/questions/3491937/i-want-to-execute-shell-commands-from-mavens-pom-xml

Этот вызов плагина, как часть задания Maven, фактически позволяет мне запускать контейнер , но у него есть огромный недостаток: жизненный цикл Maven останавливается до тех пор, пока внешний процесс не завершится или не будет остановлен вручную.

Это связано с тем, что выполнение внешнего процесса является «синхронным», а Maven не считает выполнение команды завершенным, поэтому он никогда не выполняется с остальными инструкциями по сборке.

Это не то, что мне было нужно, поэтому я искал что-то другое.

Сначала я нашел это предложение, чтобы запустить фоновый процесс, чтобы позволить Maven не блокировать: http://mojo.10943.n7.nabble.com/exec-maven-plugin-How-to-start-a-background-process -с-Exec-Exec-td36097.html

Идея здесь состоит в том, чтобы выполнить сценарий оболочки, который запускает фоновый процесс и немедленно возвращается .

и сценарий

Этот подход действительно работает . Моя сборка Maven не останавливается, и выполняются следующие шаги жизненного цикла. Но у меня сейчас новая проблема.

Мои следующие шаги немедленно выполняются.

У меня нет возможности вызвать продолжение только после того, как мой контейнер запущен и работает. Просматривая немного больше, я нашел эту хорошую статью: http://avianey.blogspot.co.uk/2012/12/maven-it-case-background-process.html Статья, очень хорошо написанная, кажется, описывает точно мою сценарий. Это также применимо к моему точному контексту, пытаясь создать вкус Карафа. Для запуска процесса в фоновом режиме используется другой подход — плагин Antrun Maven . Я попробовал и, к несчастью, нахожусь в той же ситуации, что и раньше . Интеграционные тесты выполняются сразу после запроса на запуск контейнера, но до того, как контейнер будет готов .

Убедившись, что я не могу найти никакого готового решения, я решил взломать текущее с помощью какого-то императивного кода.

Я подумал, что мог бы вставить «сценарий ожидания» после запуска запроса, но до запуска интеграционного теста, который мог бы проверить условие, которое гарантирует мне, что контейнер доступен.

Итак, если контейнер запущен на этом этапе:

и мои приемочные испытания начались в течение ближайшего

Я могу вставить некоторую логику в pre-integration-test который продолжает опрашивать мой контейнер и который возвращается только после того, как контейнер «считается» доступным.

И выполняется этим экземпляром GMaven:

Мой (некрасивый) скрипт использует логику « Успокоение» и логику на основе исключений, чтобы в течение 30 секунд проверять, будет ли доступен веб-ресурс, который, как я знаю, развертывает мой контейнер.

Эта проверка не так надежна, как хотелось бы , поскольку она проверяет конкретный ресурс, но необязательно подтверждение того, что весь процесс развертывания завершен. В конце концов, лучшим решением было бы использование некоторого API-интерфейса управления, который мог бы проверять состояние контейнера, но, честно говоря, я не знаю, выставлены ли они Карафом, и моей простой проверки было достаточно для моего случая ограниченного использования.

С вызовом GMaven, теперь моя сборка maven ведет себя так, как я хотел.

В этом посте был показан способ обогатить ваш скрипт Maven некоторой программной логикой без необходимости написания полнофункционального плагина Maven. Поскольку у вас есть полный доступ к контексту Groovy, вы можете подумать, что можете выполнить любую задачу, которая может оказаться полезной. Например, вы также можете запустить фоновые потоки , которые позволят жизненному циклу Maven развиваться, продолжая выполнять вашу логику.

Мое последнее предложение — постараться сохранить логику в ваших скриптах простой и не превращать их в длинные и сложные программы. Читаемость была причиной, по которой я решил использовать уверенность вместо прямого доступа к Apache HttpClient .

Это образец полного pom.xml