6

pom.xmlEAR アーカイブを 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

4 に答える 4

7

私がやっているときmvn deploy、mavenはdeployアーティファクトをリポジトリにしようとしています。これは私が達成しようとしているものではありません。実行段階が間違っている気がします...

Maven 用語では、デプロイはアプリケーション サーバーへのデプロイとは関係なく、この種の作業を行うプラグインをバインドする適切なフェーズではありません。ビルド ライフサイクルdeployの紹介 のフェーズについて読むことができるものは次のとおりです。

  • deploy- 統合またはリリース環境で行われ、他の開発者やプロジェクトと共有するために最終パッケージをリモート リポジトリにコピーします。

しかし、フェーズをさらに進める前に、AntRun プラグインよりも優れた仕事をする可能性がある GF (開始/停止/デプロイ/アンデプロイ/etc) と対話できるプラグインがいくつかあることに言及する必要があります (AntRun は些細なことで動作する可能性があります)。ただし、たとえば、デプロイが完了し、ビルド中にアプリケーションが準備完了状態になるのを待ちたい場合があります。このようなユース ケースでは、より高度な制御が必要です)。これらの候補は次のとおりです。

  • Maven Glassfish プラグイン: これは、ローカルまたはリモートの GlassFish インストールで使用できる GlassFish 固有のプラグインです。
  • Maven Embedded GlassFish Plugin : これは、組み込み GlassFish を実行する GlassFish 固有のプラグインです。ポータブル ビルドに適しています。
  • Maven Cargo Plugin : GlassFish 3 をサポートするようになったコンテナーに依存しないプラグインです。

どちらを使用するかは、ユースケースによって異なります。多くのコンテナーにデプロイする予定がない場合は、GlassFish 固有のプラグインが最も強力です。Cargo の優れた点は、統一された API を提供することです。ただし、特に慣れていない場合、その構成は直感的ではありません。

さて、開発中にアプリケーションをデプロイしたいだけで、ビルドがコンテナーとやり取りしたくない場合、これらのプラグインを特定のフェーズにバインドすることはあまり役に立ちませんが、開発中にアプリをデプロイする人もいます。.package

ただし、ビルドの一部としてコンテナーに対して統合/機能テストを実行したい場合があります。これは実際には完全に有効で非常に一般的な使用例であり、これを実装するための関連フェーズは次のとおりです。

  • pre-integration-test: 統合テストを実行する前に必要なアクションを実行します。これには、必要な環境のセットアップなどが含まれる場合があります。
  • integration-test: 必要に応じてパッケージを処理し、統合テストを実行できる環境にデプロイします。
  • post-integration-test: 統合テストの実行後に必要なアクションを実行します。これには、環境のクリーンアップが含まれる場合があります。

このpre-integration-testフェーズは通常、コンテナーを開始し、コンテナーにアプリケーションをデプロイするために使用されます。このpost-integration-testフェーズは、アプリケーションのアンデプロイとコンテナーの停止に使用されます。

したがって、サーバーへのデプロイは典型的なビルド アクティビティであり、非常に有効なユース ケースがあり、これは Maven によって十分にサポートされていると思います。ただし、ビルドの一部として開発サーバー (および運用サーバー) にデプロイしません。

こちらもご覧ください

于 2010-07-23T21:48:31.647 に答える
3

scdef の回答に加えて、cargo プラグインの使用方法の簡単な例を次に示します: http://blank.jasonwhaley.com/2010/03/automated-deployment-with-cargo-drive.html。私は個人的にそれをフェーズにバインドしませんでした。なぜなら、maven の呼び出しごとにデプロイを実行したくなく、プラグインの呼び出しを処理するために別の pom/profile を作成するつもりがなかったからです。

さらに、アプリケーションをコンテナーに配置するだけでなく、環境内に変更が必要な他のアプリケーション/データベース/システムがほぼ常に存在する安定した環境にアプリケーションをデプロイするために、maven をまったく使用しないことをお勧めします。生産はほとんどの場合、この範囲に該当します。このコンテキストで .war/.ear/whatever デプロイメントをコンテナー/サーバーに調整することは、実際にアプリケーションを構築することから分離する必要があります。このような展開は、外部スクリプトまたはおそらくPuppetのような包括的なツールに任せてください。

于 2010-07-23T19:21:37.343 に答える
1

あなたの質問に対する直接的な回答ではないかもしれませんが、貨物プラグインを見てください: http://cargo.codehaus.org/

この正確なニーズに対応します（とりわけ）

于 2010-07-23T19:03:40.980 に答える
0

私は、Maven の ant プラグインでコピー タスクを使用して、その動作を実装しました。

これを行うための正しいフェーズは、パッケージ フェーズです。

詳細については、 http://maven.apache.org/plugins/maven-antrun-plugin/index.htmlを参照してください。

よろしく。

于 2010-07-23T23:10:27.313 に答える