問題タブ [maven-enforcer-plugin]

Maven Enforcerプラグインを使用して、パスに重複するクラスがあるかどうかを確認したいと思います。

ここから例を試してみました。

しかし、私がこのように実行すると：

mvn enforcer:enforce

このエラーが発生します：

プロジェクトデータポピュレーターでゴールorg.apache.maven.plugins：maven-enforcer-plugin：1.0.1：enforce（default-cli）を実行できませんでした：ゴールorg.apache.maven.plugins：maven-enforcerのパラメーター'rules' -plugin：1.0.1：enforceが見つからないか無効です

これを正しく使用する方法はありますか？

編集＃1

設定をこれに変更する場合：

同じエラーが発生します。

そのプロジェクトが依存関係管理を使用していることを確認する maven-enforcer ルールを作成しようとしています。

しかし、現在のプロジェクトの pom.xml に書かれているバージョンを取得するのに苦労しました。DependencyNode#getPremanagedVersion() がそれを提供すると思っていましたが、依存関係によって設定されたバージョンを返しているようです (つまり、log4j は jbossall-client に設定されています)。

現在の pom.xml で依存関係のバージョンを取得するにはどうすればよいですか?

一意でないスナップショット（Maven 3でサポートされている唯一の種類のスナップショット）を使用したマルチモジュールビルドで、maven-enforcerルールが失敗するプロジェクトがあります。

たとえば、->が「依存」関係であると仮定します。

1. モジュール-A->モジュール-B->モジュール-C
2. モジュール-A->モジュール-C

モジュールBとモジュールCは、一意のビルドとしてスナップショットリポジトリに存在します。POMで宣言されているすべてのモジュールバージョンは、現在1.0-SNAPSHOTです。

ここで、モジュールAの構築は失敗します。

mvn -pl Module-A install

結果：

推移的な依存関係は非一意のスナップショットビルドとして解決されますが、直接の依存関係は一意のスナップショットビルドとして解決されます。

私はmaven3.0.3、maven-enforcer1.0.1を使用しています。リポジトリは、一意のスナップショットオプションを使用するArtifactory 2.4.2です（Maven 3は一意でないスナップショットをサポートしなくなったため、Artifactoryが推奨しています）。

ソリューション？

更新：アーティファクトにより、Mavenクライアントの動作をオーバーライドし、一意でないスナップショットをリポジトリに保存できるように見えます。ただし、何らかの理由でArtifactoryはこれを推奨していません（ http://wiki.jfrog.org/confluence/display/RTF/Local+Repositoriesの「Maven3」の宣伝文句を参照）ので、他のソリューションは引き続き歓迎されます。

さまざまなLinuxディストリビューションでディストリビューション固有のビルドを実行するためのカスタムエンフォーサールールを作成してテストしました。提供されているビルドスニペットを使用して、mvn enforcer:enforceコマンドで適切にテストします。pom.xml

頭を悩ませて多くの実験的なテストを行った後、このカスタムエンフォーサールールをプロファイルアクティベーションセレクターとして使用する方法が見つからないようです。

「プロファイルの概要」ページの「ビルド中にどのプロファイルが有効であるかを確認するにはどうすればよいですか」セクションでmaven-enforcer-rules詳しく説明されているように、プロファイルのアクティブ化で使用されるヒントがいくつかあります。つまり、複数の文字列値（os nameなど）を持つすべてのプロファイルアクティベーションは、対応するMavenエンフォーサールールを参照します。ただし、カスタムプロファイルアクティベーターをpom.xmlに直接含めることは明らかではないようであり、そのようなものを追加するには、pomバージョンの更新が必要になる可能性があります。

Maven3は非常に柔軟な方法で拡張可能ですが、Maven拡張メカニズムによってエンフォーサールールの包含をフックすることは可能ですか？カスタムライフサイクル参加者を含める方法に関するドキュメントがあります。ただし、ビルドが開始されるまでに、プロファイルのアクティブ化がすでに行われている可能性があります。ドキュメントはまばらですが、javadocは、AbstractMavenLifecycleParticipant.afterProjectsRead(MavenSession session)「すべてのMavenProjectインスタンスが作成された後」と呼ばれることを示しています。これは、それが呼び出されるのがプロファイルのアクティブ化の前か後かという疑問を私に残します。私は後で疑っています、またはどのように適切に構成されますMavenProjectか？

プロファイルアクティベーションのカスタマイズがリモートでも可能かどうか誰かに教えてもらえますか？

maven-enforcerプラグインのbannedDependenciesルールを使用して、特定のSpringバージョン（3.1.2）を適用したいと思います。

これは、それを実現するためにエンフォーサープラグインを構成する正しい方法ですか？

上記は機能しているようmvn enforcer:enforceで、コマンドラインでを実行すると、v3.1.0またはorg.springframework：spring-oxmが推移的な依存関係として取り込まれていることが強調されました。

また、 dependencyConvergenceルールを使用したい場合もあるようですが、Mavenによって「競合」として自動的に除外される多くの依存関係エラーが強調表示されます。

これはもう少しコンテキストのあるスニペットです：

私は最近、Maven Enforcer Pluginを使用して、すべての POM がプロパティを定義することを義務付けましたfoo.bar。私はこのステートメントを会社の POM に入れ、それが私の子プロジェクトに適用されると想定しました。

がっかりしたことに (驚きではありませんが)、この規則は私の会社の POM にも適用されていました。その結果、プレースホルダーfoo.barプロパティを忠実に定義し、完了したと思いました。

残念ながら、すべての子プロジェクトはこのプロパティを継承するため、エンフォーサー テストに合格します。子供たちがこのプロパティを明示的に定義したのか、単に意味のない値を継承したのかを判断できないままです。誰でも次のいずれかの方法を提案できますか:

• この (特定の) ルールが私の会社の POM に適用されないようにします。また

• プレースホルダー プロパティが子プロジェクトに継承されないようにします。また

• 私の問題を別の方法で解決しますか？

参考までに、私のエンフォーサ ルールの定義を以下に示します。このスニペットは、私の会社の POM からのものです。

私の目標は、このプロパティ値を SCM タグ付け命令の一部として自動的に使用することでした。私の会社の POM には、子プロジェクトの適切なタグ付けスキームを定義する次のスニペットがあります。

maven-enforcer-plugin を使用して、依存関係の収束の問題を確認します。典型的な出力は次のようになります。

このメッセージを見て、私は通常、推移的な依存関係を除外することで「解決」します。

これが本当に修正であるかどうか、およびこの方法でライブラリを除外することに伴うリスクを理解したいと思います。私の考えでは：

• 新しいバージョンを使用することを選択している場合、「修正」は通常安全です。これは、下位互換性を維持しているライブラリ作成者に依存しています。

• 通常、Maven ビルドへの影響はありません (より近い定義が優先されるため) が、依存関係を除外することで、この問題について知っていることを Maven に伝え、maven-enforcer-plugin を緩和します。

私の考えは正しいですか?この問題を処理する別の方法はありますか? 一般的なケースに焦点を当てた回答に興味があります-junit上記の例は少し奇妙です。

Maven プロジェクトがあり、通常は Eclipse で編集します。一部の開発者は、org.eclipse.m2e ライフサイクル マッピング プラグインに関する情報を、きれいな pom.xml の pluginManagement セクションに追加し続けています。代わりにEclipseワークスペースに追加したほうがいいです。

私はそれを防ぎたいと思っており、話すことはオプションですが、自動施行と組み合わせることをお勧めします.

私は他のいくつかのチェックに「maven-enforcer-plugin」を使用していますが、それは明らかに行くべき場所のようです。

「禁止されたプラグイン」ルールを試してみましたが、そのルールは builds->plugins セクションにのみ反応し、builds->pluginManagement->plugins には反応しません

「ビーンシェルの評価」も試しましたが、プロパティを介してポンポンの正しいセクションに到達する方法を理解できませんでした

既存のルールで既にサポートされている場合は、カスタム ルールを作成したくありません。

これを行う方法を知っている人はいますか？

収束ルールで maven-enforcer-plugin を使用しようとしています。1つを除いてすべての問題を取り除くことができました。プロジェクトで gwt を使用しており、スコープが提供されたクライアント側で hibernate-validator 4.1.0.Final が必要です。サーバー側では、いくつかの新しい機能が必要なため、hibernate-validator 4.2.0.Final が必要です。4.1.0.Final 依存関係には分類子ソースがあります。このようにして、両方のバージョンを 1 つの pom に含めることができます。すべて正常に動作しますが、enforcer-plugin は満足できず、失敗します。

この「問題」を許可するようにプラグインを構成する方法はありますか?

編集：

よろしく、アルネ