22

なぜこれが機能しないのですか？プロパティファイルからバージョン番号を選択する方法。

pom.xmlのプロパティの読み取り

<project>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
          </execution>
          <configuration>
            <files>
              <file>dev.properties</file>
            </files>
          </configuration>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

dev.properties内

org.aspectj.aspectjrt.version = 1.6.11

pom.xmlの依存関係

        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>${org.aspectj.aspectjrt.version}</version>
        </dependency>

エラー：依存関係は有効なバージョンである必要があります

4

2 に答える 2

98

コマンドラインから Maven を起動すると、いくつかの段階を経ます。これはこれらの段階の疑似説明です。意図的に正確な順序を単純化しています (わずかに間違っている/順序が正しくないことを言うリスクがあります)。これにより、実行しようとしていることが機能しない理由がわかります。

  1. 最初にコマンド ラインを解析し、 を使用してコマンド ラインで定義されたすべてのプロパティ-Dname=valueがMavenSession

  2. コマンド ライン オプションを定義するリアクターがチェックされ、ビルドするプロジェクトのリスト (リアクターとも呼ばれます) が決定されます。-Nは、ルートのみをビルドすることを意味し、ビルドするpom.xmlモジュール-plのリストを指定できるようにし、 で-am指定-amdされたモジュールから上流または下流のモジュールをそれぞれ追加できるようにします-pl。pom.xmlこの時点で、Maven はファイルを解析していません。

  3. -Pどのプロファイルをアクティブにするかを確認するために、プロファイルのアクティブ化ルールが解析されます。

  4. これで、Maven はpom.xmlファイルの解析を開始するのに十分な知識を得ました。root pom.xml、つまり現在のディレクトリにあるもの (または、その代替pom.xmlを指定した場合-f) を読み込んで解析することから始めます。この最初の解析は、ビルドするプロジェクトのリストを把握することに集中しているだけです。プロファイルのアクティブ化は、使用可能なリストに影響を与える可能性がある場合にのみ考慮され<modules>ます。のグループ ID、アーティファクト ID、バージョン、およびパッケージの座標にpom.xmlはプロパティを含めることができません。これは、 のプロパティの解析がpom.xmlこの時点で行われていないためです。(注意深い読者は、これが、なぜプロファイル内のプロパティに基づいてプロファイルをアクティブ化できないかを説明していることにも気付くでしょう。pom.xml、この段階ではシステム プロパティのみが解析されているため)

  5. プロジェクトのセットが検証されると、Maven はこれらのpom.xmlファイルをさらに解析して、ビルド拡張機能 (存在する場合) のリストとプラグインのリストを作成します。この段階で、解析には<properties>各プロジェクトの評価が必要になるため、これらが評価されて有効なモデルに「注入」されるのはこの段階です。したがって、システム プロパティと pom プロパティを使用して、 (xpath) /project/build/extensions、/project/build/pluginManagement/plugins/plugin、/project/build/pluginManagement/plugins/plugin/dependencies、/project/build/plugins/pluginおよび内の座標と追加の依存関係を定義できます/project/build/plugins/plugin/dependencies。

  6. ここで、Maven は、コマンド ラインで指定された目標とフェーズのリストの解析を開始します。部分的に指定された目標は、プラグインのリストとの一致について評価されます。一致は、プラグイン ゴールが実行されるすべてのプロジェクトに対して一意である必要があります (つまり、アグリゲーター ゴールの場合、一致はルートでのみ必要ですが、他のすべての「通常の」ゴールの場合、プラグインの短い名前はすべてのプロジェクトで同じプラグイン)。ライフサイクル フェーズは、既定のライフサイクルのいずれか、またはビルド拡張機能で定義されたライフサイクルからのものである必要があります。

  7. 解析された目標とフェーズのリストから、Maven はビルド計画、つまり、どのプロジェクトで何をどの順序で実行するかを構築します。これを行うために、Maven は、リアクター プロジェクトpom.xmlファイルで定義されたプロジェクトの依存関係のリストを解析する必要があります。これは、reactor 内の別のプロジェクトによって依存関係が生成される可能性があり、それによってプロジェクト実行の順序付けが強制されるためです。したがって、システム プロパティと pom プロパティを使用して (xpath) 内の座標と追加の依存関係を定義できますが/project/dependencyManagement/dependencies/dependency、/project/dependencies/dependency この時点ではプラグインは実行されていないことに注意してください。

  8. Maven はビルド計画を作成したので、構築した順序でその計画に従い始めます。CLI の最初の目標/フェーズが目標であった場合、その目標が呼び出されます。最初の目標/フェーズがデフォルトのビルド ライフサイクルのフェーズであった場合、Maven はそのフェーズから開始し、そのinitializeフェーズにバインドされているすべてのプラグインを実行します...同様の方法で、フェーズのリスト、次にプロジェクトのリストに沿って続行します. また、initializeフェーズは、デフォルトのビルド ライフサイクルの一部としてのみ実行されます。デフォルトのクリーンまたはデフォルトのサイト ライフサイクルでは実行されず、カスタム ライフサイクルでも実行されません。(注意深い読者は、これが質問が試みているテクニックの別の問題を浮き彫りにしていると結論付けるでしょう)。注: アグリゲーターのゴールはリアクターで「ブレーク」を形成することに注意してください。そのため、Maven にアグリゲーターのモジョ ゴールを実行するように要求するclean package foo:bar siteとfoo:bar、clean packageリアクター内のすべてのプロジェクトに対してfoo:bar実行され、ルートに対して実行されます。 、siteリアクター内のすべてのプロジェクトに対して実行されます。言い換えれば、ビルド計画は、アグリゲーターの目標の最長の連続実行によって分割された、非アグリゲーターの目標とフェーズの最長の連続実行を取得します。

  9. 各モジョを呼び出す前に (つまり、フェーズにバインドされたゴール、またはコマンドラインから直接指定されたゴール)、Mavenはそのモジョpom.xmlの有効性を評価します。<configuration>この時点で、Maven はシステム プロパティ、pomで指定されたプロパティ、およびMavenSession以前に実行された mojo によって注入されたプロパティを使用できます。したがって、<configuration>これらのプロパティのいずれかを参照できます...

    さておき

    ここで注意点があります... set (xpath)/project/build/directoryを に設定し${some-property-i-will-set-via-a-mojo}、それを から参照すると<configuration>、残念なことに (xpath)はプラグインの実行前/project/build/directoryに有効に評価されるため、リテラル値であり、それは の型であるため、実際に発生したのはです。注入するフィールドが typeの場合、型変換は必要ないため、値は直接注入され、プロパティの置換は行われません。pom.xml ${project.build.directory}${some-property-i-will-set-via-a-mojo} java.io.FileMavenProjectnew File(project.getBaseDir(),"${some-property-i-will-set-via-a-mojo}")<configuration>File

    上で概説したような他のエッジケースがありますが、一般的にプロパティ置換は、セクション内の「mojo が注入された」プロパティ ( Mojo の Properties Maven Pluginによって提供されるものなど) で機能し<configuration>ます。これらのセクションの外では機能しません。

したがって、さまざまなプロパティ タイプに対する Stephen の簡単な経験則は次のとおりです。

システムプロパティ

これらはどこでも機能します...しかし、プロジェクトが推移的な依存関係として取り込まれたときにどのシステムプロパティが定義されるかをまったく制御できないため、非常に危険です。拡張機能/project/(parent/)?/(groupId|artifactId|version|packaging)を使用することは、エアバッグの代わりにハンドルから 30cm (12 インチ) の金属スパイクを突き出して時速 200km で車を運転することと同等と見なす必要があります...ああ、シートベルトはありません...そして、あなたはただ10単位のアルコールと2系統のコカインを持っていました。${...}/project/(parent/)?/(groupId|artifactId|version|packaging)

pom.xmlプロパティ(およびsettings.xmlプロパティ)

これらはほとんどの場所で機能しますが、/project/(parent/)?/(groupId|artifactId|version|packaging)(これらのフィールドが評価されているときに解析されていないため) 内部で使用することはできず、アクティブなプロファイルの検討には使用できません (プロファイルのアクティブ化が評価されているときに解析されていないため)。

モジョ注入プロパティ

これらは<configuration>セクション内で機能し、(注入された Mojo パラメーターの再帰的補間によりString) 間接的に使用すると機能する可能性がありますが、関連する不確実性を考慮して、<configuration>プラグインとレポートのセクションのみに使用を制限することをお勧めします。

最後に 1 つ

プロジェクトが依存関係としてリストされた場合に何が起こるかを考えてみてください。mojo を使用し.propertiesてディスク上のファイルから依存関係をプルすることで依存関係を指定した場合、依存関係が Maven リポジトリからプルされたときに、Maven はそれを複製する方法がありません。そのため、Maven は依存関係を判別できません。したがって、それは決して機能しませんでした。

あなたができることは、外部システム（ANTなど）を使用して、pom.xmlそのファイルに置き換えられたバージョンでテンプレートから を生成することです。次に、インスタンス化されたテンプレートを使用してビルドします。

于 2013-02-06T10:44:32.063 に答える
-2

ビルドジョブ用のこのproperties(dev.properties)ファイル。

<files>
   <file>dev.properties</file>
</files>

依存関係については、pom.xmlファイルに以下のように追加する必要があります。

<properties>

<org.aspectj.aspectjrt.version>1.6.11</org.aspectj.aspectjrt.version>
</properties>
于 2013-02-06T09:10:19.983 に答える