だから私自身の質問に答える:D私が思いついたソリューションはCIでは機能しません。プロジェクトの相対パスを使用するため、ローカルビルドを実行する場合にのみ機能する可能性があります。下部では、Eclipse と CI を満たす必要がある、より堅牢であるがより複雑なアプローチについて概説します。
war プロジェクトの war プラグイン構成で attachClasses を true に設定することを検討していました。
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
</plugins>
次に、依存プロジェクトで jar を次のように参照できます。
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>storage-service-war</artifactId>
<version>${project.version}</version>
<classifier>classes</classifier>
</dependency>
次に、埋め込まれた jetty または tomcat を使用して受け入れテスト モジュール内からテストを実行し、それらを相対パスを使用して war プロジェクトで定義された web.xml にポイントできると考えていました。
これは、コマンドラインを介してmavenで正常に機能しますが、Eclipseでは失敗します:(
これに関する問題は、アタッチ クラスによって生成された jar が Eclipse m2e 統合によって取得されないことです。https: //bugs.eclipse.org/bugs/show_bug.cgi?id=365419残念ながら修正されません。
したがって、当面の私の解決策は、 storage-service-war プロジェクトを Eclipse の受け入れテスト プロジェクトのビルド パスに手動で追加することです。それは素晴らしいことではありませんが、うまくいきます
上記の解決策は少しハックですが、概説されている代替案はもう少し複雑です。
プロジェクトを次のように分割することで、正しいEclipse統合とCIで動作するプロジェクトを持つことが可能になると思います
storage-service
storage-service-core
storage-service-war
storage-service-acceptance-tests
storage-service-config
コア プロジェクトには webapp のロジックとソースが含まれ、タイプは jar です。構成には web.xml とその他の構成ファイルが含まれ、タイプも jar です。次に、受け入れテストと戦争プロジェクトは両方ともタイプが戦争であり、コアプロジェクトを戦争にパッケージ化し、構成を webapp/WEB-INF ディレクトリに抽出して、共通のセットアップを共有できるようにするだけです。