4

いくつかの J2EE プロジェクトを Ant から Maven2 に移植中です。これらのプロジェクトはすべて、1 つの EJB と 1 つの Web モジュールを含み、推奨される「スキニー」EAR パッケージ方式を使用します。これは、EJB や Web モジュールが依存する JAR がすべて EAR のルートに配置されることを意味します。EJB と Web モジュールの両方に、それぞれのマニフェストに Class-Path エントリがあり、特定の JAR を参照します。また、Web モジュールの Class-Path も EJB jar を参照します。

Maven がこれをうまくサポートしていないことに気がつきました (それは強すぎますか? :))。スキニー WAR の処理に関する公式ページを読みましたが、EAR pom で WAR 依存関係を複製する必要があり、さらに悪いことに、推移的な依存関係も複製する必要がありました。どこでも依存関係を手動で処理する必要がある場合、Maven を採用するのは無意味に思えます。

その後、Google を開始し、さまざまな回避策を見つけました。明らかに、(a) スキニー EAR を実行したい、(b) Maven が提案するアプローチ (それ自体が回避策) が気に入らないというのは、私が初めてではありません。

これらのアプローチのいくつかを試しましたが、どれもうまくいきませんでした。また、Maven のバグのように見える問題もいくつか見つかりました。たとえば、WAR プラグインの「packagingExcludes」ディレクティブは、直接的な依存関係のみを除外し、推移的な依存関係は除外しません。あまり自信がありません。この特定の JIRA の問題を見つけましたが、まだ開いています。

その後、私のコマンドライン Maven 2.2.1 は、私の m2eclipse 組み込み Maven (Embedder v. 3.0) とは異なる動作をすることがわかりました。私たちの開発者は間違いなく Eclipse から Maven を動かしたいと思っていたので、最新のコマンドライン バージョンに依存するという選択肢はありませんでした。

ですから、私の質問は次のとおりです。現在、そして当面の間、すべての開発を Eclipse で行い、主にスキニー EAR プロジェクトで作業する場合、Maven に移行する価値はありますか? Maven の将来に、より堅牢で統合された方法で EAR を処理するものはありますか?

4

3 に答える 3

3

ですから、私の質問は次のとおりです。現在、そして当面の間、すべての開発を Eclipse で行い、主にスキニー EAR プロジェクトで作業する場合、Maven に移行する価値はありますか? Maven の将来に、より堅牢で統合された方法で EAR を処理するものはありますか?

短編小説: いいえ、M2Eclipse が壊れたままではありません。

長い話：

現時点では、少なくとも Eclipse では推奨しません。執筆時点で、M2Eclipse プラグインには非常に厄介なバグがあり、Maven が作成するファイルを使用するのではなく、独自のバージョンの application.xml 記述子ファイルを生成します。

残念ながら、このカスタム作成された application.xml はまったく間違っています。finalNames を無視し、明らかにハードコードされた "lib/" プレフィックスを持ち、何らかの理由で EJB JAR に拡張子 ".ejb" を割り当てます。さらに悪いことに、M2Eclipse によって再生成され続けるため、削除して Maven のバージョンに置き換えることはできません。

Maven は、application.xml がまだ配置されていない場合にのみ生成します。WTP/M2Eclipse で生成された application.xml が再生成され続けるため、Maven の application.xml にはチャンスがありません。

ただし、この問題には回避策があります。パッケージ化中に application.xml を無視するように Maven に指示して、application.xml が存在しないと見なすことができます。その場合でも、独自のバージョンが生成されます。そうすれば、誤って生成された application.xml ファイルは問題になりません。今後の参考のために：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <version>5</version>
        <earSourceExcludes>**/application.xml</earSourceExcludes>
        <generateApplicationXml>true</generateApplicationXml>
    </configuration>
</plugin>

ただし、大きな問題の 1 つは、Eclipse で GlassFish へのデプロイに使用される Ant スクリプトが、デプロイ用に独自の個別の EAR を生成し、そのために M2Eclipse で生成された application.xml を使用することです。つまり、M2Eclipse プラグインが壊れている限り、生成される EAR は常に間違っています。codehaus JIRA にはこれに関するバグ レポートがありますが、現在はアクセスできません。

他のアプリケーション サーバーには YMMV を使用しますが、application.xml をいじるのに十分な準備が必要です。

于 2010-04-22T23:56:35.273 に答える
1

残念ながら、このカスタム作成された application.xml はまったく間違っています。finalNames を無視し、明らかにハードコードされた "lib/" プレフィックスを持ち、何らかの理由で EJB JAR に拡張子 ".ejb" を割り当てます。さらに悪いことに、M2Eclipse によって再生成され続けるため、削除して Maven のバージョンに置き換えることはできません。

これを行っているのはm2eclipseだと本当に確信していますか? 私は m2eclipse 統合を含む JBoss Tools 3.1 を使用しており、あなたが述べている問題を正確に解決しています。ただし、m2eclipse がソース application.xml を気にする理由がまったくわかりません。

私の疑いでは、JBoss Tools が application.xml に情報を注入するということです。私が間違っていることを証明してください。/target の下にないものを変更した場合、m2eclipse の使用を永久に停止します。

//GG

于 2010-06-03T10:00:07.377 に答える
0

Mavenがこれをうまくサポートしていないことに気がつきました(それは強すぎますか? :))。

実際、Maven はスキニー WAR ( Solving the Skinny Wars problem wiki ページも参照) をあまりサポートしていません。これは最初から計画されておらず、Maven がファット WAR を想定しているためです。したがって、スキニー WAR とスキニー EAR を構築する方法は、実際には、既存のプラグインの上に構築された回避策です。そして、はい、これはエラーが発生しやすいです。

(...) その後、私のコマンドライン Maven 2.2.1 は、私の m2eclipse 組み込み Maven (Embedder v. 3.0) とは異なる動作をすることがわかりました。

組み込み Maven の代わりに外部 Maven を使用するように m2eclipse を構成できることに注意してください。これは実際に私が行っていることであり、CI エンジンが使用するものとまったく同じバージョンが必要です。

ですから、私の質問は次のとおりです。現在、そして当面の間、すべての開発を Eclipse で行い、主にスキニー EAR プロジェクトで作業する場合、Maven に移行する価値はありますか?

私のアドバイスは単純です。Maven があなたが望むソフトウェアの構築方法をサポートしていない場合 (正当かどうかは問題ではありません)、それを使用しないでください。

于 2010-02-10T15:15:41.260 に答える