0

マルチモジュールのmavenプロジェクトがあります。プロジェクトのレイアウトは次のとおりです。

PARENT
  |-CHILD1
  |-CHILD2

親プロジェクトには pom パッケージ タイプがあり、モジュールとして宣言CHILD1およびプロジェクトを行います。CHILD2また、PARENTプロジェクトは、いくつかのプロパティを宣言するプロファイルdevを宣言します。devCHILD1 プロジェクトには jar パッケージ タイプがあり、いくつかの依存関係 (依存関係など) を追加することでPARENT プロファイルを「オーバーライド」しますcommons-collections。CHILD2 プロジェクトには war パッケージ タイプがあり、CHILD1 プロジェクトに依存しています。devまた、CHILD2は、別の依存関係を追加することによって親プロファイルを「オーバーライド」します (commons-ioたとえば、プロジェクト CHILD1 の依存関係とは関係のない依存関係を意味します)。次に、mvn clean install -Pdevmavenを実行するcommons-collections.jarと、(CHILD1 プロジェクトで宣言されている依存関係) が CHILD2 プロジェクトに配置されませんWEB-INF/libが、commons-io.jar はそこにあります。

問題は、ターゲット プロジェクトがそのプロファイルで別の依存関係のセットを宣言している場合、ターゲット プロジェクトの依存プロジェクトで宣言されているプロファイルから依存関係を配置しないのはなぜですか?

実際、私はより多くのプロジェクトと、さまざまなプロファイルで異なるより多くの依存関係を持っています。そして、そのプロジェクトpom.xmlでプロジェクト固有の依存関係を宣言したい(プロジェクトでプロファイルを宣言すると、親プロファイル宣言が「オーバーライド」されると仮定)

4

1 に答える 1

2

開発時にローカルでテストし、ステージング環境に対して変更をテストし、最終的に本番環境にデプロイできるようにしたいと考えています。

心に留めておく必要がある重要なことは、アーティファクトがローカル/リモート リポジトリにデプロイされるとき、アクティブなプロファイルはデプロイされるものの一部ではないということです。 Web アプリケーションが DEV プロファイルをアクティブにしてビルドされたのか、PROD プロファイルをアクティブにしてビルドされたのかを知る方法であり、そのビルドされたアーティファクトが本番環境にデプロイされたときに、大失敗する可能性があります。

つまり、アーティファクトがデプロイメント環境から独立していることを確認する必要があります。

これは、たとえば、次から構成を取得することを意味します。

  • クラスパス上のファイル
  • システムプロパティ
  • jndi エントリ

たとえば、Tomcat にデプロイする場合、configuration.properties を$CATALINA_HOME/lib

起動時の webapp はgetClass().getResource('/configuration.properties')、プロパティ ファイルを解決するために使用し、ファイルが見つからない場合は起動に失敗します (フェイルファースト)。

に configuration.properties のテスト バージョンを配置することで、ユニット/統合テストで別の構成を使用できるようになりますsrc/test/resources。

<scope>provided</scope>アプリケーションのスタイルの依存関係にも同じ原則を使用します。つまり、コンテナーが提供することで契約されている依存関係は、コンテナーによって提供される必要があります。そのため、Maven を使用して tomcat/jetty の製品版を自分でビルドし、必要な依存関係をそのアセンブリに追加することができます。これは、本番バージョンが MySQL データベースを使用するようなものであるため、mysql-jdbc ドライバーを に追加する必要があります$CATALINA_HOME/lib。実際には、一部のビットを含めて他のビットを除外して zip を再パックするだけなので、アセンブリ プラグインを使用してこれを行うのは比較的簡単です。

ローカルでテストする場合は、 や などのヘルパー プラグインのrunゴールを利用する必要がjetty:runありtomcat:runます。ここでの解決策は、プラグインのクラスパスにのみ影響を与えているアーティファクトの依存関係に影響を与えていないため、プロファイルを介してこれらのプラグインの依存関係を与えることには何の問題もないということです。

例えば

<project>
  <!-- ... some stuff .. -->
  <profiles>
     <profile>
       <id>DEV</id>
       <build>
         <plugins>
           <plugin>
             <groupId>org.mortbay.jetty</groupId>
             <artifactId>jetty-maven-plugin</artifactId>
             <dependencies>
               <dependency>
                 <groupId>commons-dbcp</groupId>
                 <artifactId>commons-dbcp</artifactId>
                 <version>1.4</version>
               </dependency>
               <dependency>
                 <groupId>mysql</groupId>
                 <artifactId>mysql-connector-java</artifactId>
                 <version>5.1.18</version>
               </dependency>
             </dependencies>
           </plugin>
         </plugins>
       </build>
     </profile>
   </profiles>
 </project>

システム プロパティまたはクラスパスの追加を構成して、必要な構成ファイルを取得することもできます。

これらすべての最終結果は、アーティファクトが環境に依存しないままであり、さまざまな環境に対して簡単にテストできることです。

これがあなたの質問に答えてくれることを願っています（横向きであっても）

于 2012-08-14T12:06:38.887 に答える