Какова правильная фаза maven2 для развертывания на сервере приложений? - PullRequest
Новая
       31

Какова правильная фаза maven2 для развертывания на сервере приложений?

6 голосов
/ 23 июля 2010

Я пытаюсь настроить pom.xml, чтобы он автоматически развертывал архив EAR на сервере приложений GlassFish.Я хочу присоединить эту операцию к правильному этапу maven выполнения .Но не можете понять, какой из них предназначен только для этой операции?Развертывание?Установить?Пожалуйста помоги.Вот что я делаю: 

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
        <execution>
            <phase>deploy</phase>
            <configuration>
                <tasks>
                    <copy file="${project.build.directory}/${project.build.finalName}.ear" 
                        tofile="${glassfish.home}/domains/domain1/autodeploy"/>
                </tasks>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Когда я делаю mvn deploy, maven пытается развернуть мои артефакты в хранилище.Это не то, что я собираюсь сделать.Я чувствую, что фаза исполнения не так ..

Ответы [ 4 ]

7 голосов
/ 24 июля 2010

Когда я делаю mvn deploy, Maven пытается deploy мои артефакты в хранилище.Это не то, что я собираюсь сделать.Я чувствую, что фаза выполнения неправильная ...

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

  • deploy - выполненном в среде интеграции или выпуска,копирует окончательный пакет в удаленный репозиторий для совместного использования с другими разработчиками и проектами.

Но, прежде чем перейти к этапам, я должен упомянуть, что есть несколько плагинов, позволяющих взаимодействовать сGF (start / stop / deploy / undeploy / etc), которая может выполнять работу лучше , чем плагин AntRun (AntRun может работать для тривиальных случаев использования, но, например, вы можете подождать, пока развертываниебыть готовым и приложение должно быть готовым во время сборки; для таких случаев использования требуется более продвинутый контроль).Вот следующие кандидаты:

  • Плагин Maven Glassfish : это специальный плагин GlassFish, который можно использовать с локальной или удаленной установкой GlassFish.
  • the Maven Embedded GlassFish Plugin : это специальный плагин GlassFish, который запускает встроенный GlassFish.Отлично подходит для переносимых сборок.
  • Плагин Maven Cargo : этот плагин-контейнер, который теперь поддерживает GlassFish 3.

Использование одного или другого действительно зависит отваш вариант использования.Если вы не планируете развертывать во многих контейнерах, специальные плагины GlassFish являются наиболее мощными.Прелесть Cargo в том, что он предлагает единый API.Но его конфигурация менее интуитивна, особенно если вы к ней не привыкли.

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

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

  • pre-integration-test: выполнить действия, необходимые перед выполнением интеграционных тестов.Это может включать такие вещи, как настройка требуемой среды.
  • integration-test: обрабатывать и развертывать пакет, если необходимо, в среде, где можно запускать интеграционные тесты.
  • post-integration-test: выполнятьдействия, требуемые после выполнения интеграционных тестов.Это может включать в себя очистку среды.

Фаза pre-integration-test обычно используется для запуска контейнера и развертывания на нем приложения.Фаза post-integration-test используется для отмены развертывания приложения и остановки контейнера.

Так что я думаю, что развертывание на сервере может быть типичным процессом сборки, есть очень допустимые варианты использования, и это хорошо поддерживается Maven.Я не развертываю ни на своем сервере разработки (ни на рабочем сервере) как часть сборки.

См. Также

3 голосов
/ 23 июля 2010

В дополнение к ответу scdef, вот краткий пример того, как выглядит грузовой плагин: http://blank.jasonwhaley.com/2010/03/automated-deployment-with-cargo-drive.html. Лично я не привязал его к фазе, так как не хочу, чтобы развертывание происходило на каждомвызов maven и не намеревался написать еще один pom / профиль для обработки вызова плагина.

Кроме того, я бы порекомендовал вообще не использовать maven для развертывания моих приложений в стабильных средах, где почти всегда будут другие приложения / базы данных / системы в среде, которые необходимо изменить, кроме того, поместивприложение в контейнере.Производство почти всегда подпадает под эту область.Координация .war / .ear / независимо от развертывания на контейнере / сервере в этом контексте действительно должна быть отделена от фактической сборки вашего приложения.Оставьте развертывания, подобные этому, для внешних сценариев или, возможно, комплексного инструмента, такого как Puppet .

1 голос
/ 23 июля 2010

Это может быть не прямой ответ на ваш вопрос, но посмотрите на плагин Cargo: http://cargo.codehaus.org/

Он отвечает именно этой потребности (среди прочего)

0 голосов
/ 24 июля 2010

Я реализовал это поведение, используя задачу копирования с плагином ant для maven.

Правильная фаза для этого - фаза пакета.

Подробнее см. http://maven.apache.org/plugins/maven-antrun-plugin/index.html.

С уважением.

...