5

mavenを使用して .earを作成しています

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-ear-plugin</artifactId>
  <version>2.6</version>
  <configuration>
    <finalName>wsformatter-ear</finalName>
    <includeLibInApplicationXml>true</includeLibInApplicationXml>
    <version>1.4</version>
  </configuration>
</plugin>

.ear のすべての依存関係は、joda-time-1.6.2.jar、commons-io-1.4.jarなどのようになります。

しかし、バージョンなしで必要な依存関係もあります。たとえば、依存関係slf4j-api-1.5.6.jarは私の.earでは slf4j-api.jarのようになります。

4

2 に答える 2

18

私はミハル・カリノフスキーに完全に同意します。しかし、私は同じ状況に陥りました。実際には逆の状況です。誰かが最終的な EAR のバージョンを除外するようにプロジェクトを構成しており、私はこれをキャンセルする方法を探していました。ウェブで検索したところ、まさにこの質問が見つかりましたが、答えはコード自体にありました。以下を使用できます。

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-ear-plugin</artifactId>
   <configuration>
        <version>5</version>
    <defaultLibBundleDir>lib</defaultLibBundleDir>
    <fileNameMapping>no-version</fileNameMapping>
   </configuration>
</plugin>

タグfileNameMappingのある行は、あなたが望むものです。これが役立つことを願っています。

于 2012-10-17T21:56:28.557 に答える
2

基本的に、(Maven のプラグインの構成をハッキングしない限り) できません。できたとしても、できません。依存関係に関する Maven のアプローチと哲学は、ファイル名のサフィックスとしてバージョンを使用するというデフォルトの規則を含め、それらについて厳密かつ率直です。どのバージョンのアーティファクトが使用されているかがすぐにわかります。頻繁にリリースされるアーティファクトに依存している場合は、とにかく EAR の POM でそのバージョンを更新する必要があるため、その「伝播」は何らかの形で自動ではありません。したがって、このファイル名サフィックスに問題はないと思います。

この頻繁な変更の必要性が問題になる場合は、この頻繁にリリースされるアーティファクトの開発サイクルを何らかの方法で変更することを検討する必要がありますか? おそらく、同じ SNAPSHOT バージョンの間に費やす時間を少し延長できますか? 頻繁に「内部」リリース (ナイトビルドなど) を行う場合でも、Maven は (Maven Release Plugin の意味で) リリースごとにバージョンを上げることを強制しません。必要な限り、いくつかの SNAPSHOT バージョンを使用できます。非常に迅速なアジャイル プロセス (またはかんばん) でさえ、この種の「実際の」リリースは通常、数週間ごとに発生し、管理しやすいほど十分な長さです。

結局のところ、私はあなたを助けない（またはこのようなもの）、またはしたくないのはこのようなものではありません。Mavenに逆らおうとしているだけだと思います。Maven は、そのアプローチと規則を受け入れて従えば、非常に強力です。私の経験からすると、これを回避しようとすると、(遅かれ早かれ) 問題が発生します。私はすでに、Maven のような Ant 構成を持つ多くのプロジェクトと、Maven が最低だと不平を言っている多くの開発者を見てきました。そこにあるものを理解した後、私は彼らに言いました：「Mavenは吸わない、あなたのPOMは吸う」.

于 2012-04-10T09:49:48.240 に答える