2012-03-14 28 views
0

私は、Mavenを使うほど、特にMavenの異なるバージョンを使って同じプロジェクトをビルドしていると、私は気づいています。これは期待されていますか?一般的なMavenのバグ

例のカップル:私はJBossにデプロイしていた.earを持つ

。私がwsdls、xsdsを持ち込み、クラスパス上に持ち込まれたクラスを生成すると、.jarを依存関係として持ち込み、それを.earに展開します。これを行うために、私はアンパック依存関係の目標を使用しています。 ...このようになります(プロジェクトはもともと内蔵されたものである)のMaven 3.0.3を使用して

<plugin>    
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-dependency-plugin</artifactId> 
       <version>2.4</version> 
      <executions> 
       <execution> 
        <id>unpack-wsimport</id> 
        <phase>prepare-package</phase> 
       <goals> 
        <goal>unpack-dependencies</goal> 
       </goals> 
        <configuration> 
         <includeGroupIds>url.projectName</includeGroupIds> 
         <includeArtifactIds>projectName-wsimport</includeArtifactIds> 
         <outputDirectory>${project.build.outputDirectory}</outputDirectory> 
        </configuration> 
       </execution> 
      </executions> 
</plugin> 

、これは正常に動作します。 Maven 2.0.9に切り替えて、突然それはしません。 Mavenサイトでは、このプラグインはバージョン1.0以降でサポートされていると言われています。なぜそれは動作しませんか?

このプロジェクトのmavenリリースをしようとしているときに、Maven 2.0.9を使用すると、準備と実行は正しく行われますが、3.0.3では特定のファイルをコピーしませんSVNでバージョンをタグ付けする

プロジェクトをビルドするためにMavenのバージョンを切り替えると、他に誰かがこのようなエラーを見つけますか?

+0

別々の問題について別の質問をしてください。また、異なるメジャーリリース、2.xと3.xを使用していることにも留意してください。行動のいくつかの違いが予想されます。 Maven 2.0の事実を気にしないでください。9年前にリリースされました。 –

+0

Maven 2.0.9はもう使用しないでください。誰かがMaven 2.0を使用しなければならない場合、2.0.11にする必要があります。 – khmarbaise

答えて

0

まず、耳のようなものをやっていることを理解していないように見えます.EAR内では依存関係を追加する必要があります。依存関係は依存関係プラグインを経由せずにEARに入れます。それらを依存関係として代わりに使用します。

例のため

<build> 
    <plugins> 
     <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-ear-plugin</artifactId> 
     <version>2.6</version> 
     </plugin> 
    </plugins> 
    </build> 

    <dependencies> 
    <dependency> 
     <groupId>${project.groupId}</groupId> 
     <artifactId>webgui</artifactId> 
     <version>${project.version}</version> 
     <type>war</type> 
    </dependency> 
    <dependency> 
     <groupId>${project.groupId}</groupId> 
     <artifactId>service</artifactId> 
     <version>${project.version}</version> 
     <type>ejb</type> 
    </dependency> 
    </dependencies> 

より良いアプローチは、maven-ear-pluginの正しい構成を使用することです。

あなたが与えた情報に基づいて、EARにパッケージ化される異なるモジュール(web-part、wsdl-partなど)を含むマルチモジュールビルドが必要になると思います。これは、次のような構造に生じるであろう:あなたはマルチモジュールプロジェクトのようなプロジェクトのorginizationを検討する必要があるよう

+-- root 
     +-- pom.xml 
     +-- war 
      +-- pom.xml 
     +-- wsdl 
      +-- pom.xml 
     +-- ... 
     +-- ejb 
      +-- pom.xml 
     +-- ear 
      +-- pom.xml 

は、さらにそれが見えます。ここにはそのような種類のexampleがあります。 Mavenについてのdocumentationは、Maven by Exampleで始まる良い方法です。

私はこのことを認められません。私は本当に大きなプロジェクト(100モジュール+)でMavenと長い時間働いています...さらに、このプラグインがどこにあるのか知りたいのですがバージョン1.0で動作します。

リリースノートを読んでいるような気がしていないにもかかわらず、 Mavenのバージョン間には、特にMaven 2.0.X、2.2.X、および3.0.Xの間に大きな違いがあります。実際に2.0、2.2、および3.0のようなdifferernt Mavenバージョンでビルドを実行する必要がある場合。これを行うことができ、動作していますが、特に2.2.Xと3.0.Xの間の技術的な詳細に基づくいくつかの欠点があります(報告されています)。あなたの成果物(現在は3.0.3/3.0.4)を構築するためにMavenバージョンを1つだけ使用することをお勧めします。もう1つのヒントは、Maven 2/3で動作するMavenビルドがMaven 1で動作しないことです.POMが大幅に変更されたためです。

+0

良い答えですが、ここで問題となっているのはMavenの1つのバージョンで構築されていて、他のバージョンでは構築されていなかったからだと思います。完璧な世界では、私はMavenの1つのバージョンを使用していますが、異なるバージョンでビルドされたこれらのプロジェクトを継承し、それらを処理しなければなりません。したがって、私はMavenの下位互換性のサポートはまったく良いとは思っていません。したがって、より広い意味では、「pom」のような冗長性の概念がレンダリングされます。 – user898465

+0

たとえば、ビルドしなければならない.svnのプロジェクトを見つけたが、それをビルドするために使用されたMavenのバージョンが分からない場合は、推測する必要がありますか?このコンテキストでは、プロジェクトのビルドに使用されたMavenのバージョンを正確に知る必要があるため、pomは役に立たなくなります。 – user898465

+0

POMには小さなヒントを与えるmodelVersionがあります...この場合、少なくともMaven 2でなければなりません.Maven 1にはmodelVersion 3があります。さらにMaven 3を使用します.Mavenを使用する必要がある場合2.0私は最新の2.0.11(AFAIK)を使用するでしょう。もう1つのヒントは、pomで定義されているプラ​​グインのバージョンで、別のヒントを与えることができます。 – khmarbaise