メイク内のアーティファクトIDの一意性

Question

• 同じ groupIdを持つが、異なるアーティファクトIDを持つ2つのメイプルアーティファクト（ローカル）があるとします。
• 異なるアーティファクトIDは、各アーティファクトをユニークにする必要があります。
• ただし、両方のユニークな成果物にそれぞれが同じ名前を持つクラスがある場合。そのクラスはjavaにインポートされるときにgroupId.className形式を使用するため、一意ではありません。 groupIdとclassNameのどちらもユニークではありません。
• これにより、使用するクラスを決定する際のあいまいさが発生します。
• テストすると、pom.xmlファイルで最初に宣言された依存関係が使用されているようです。

質問のベストプラクティスは何を解決している/この問題を回避する？

1. ですか
2. なぜmavenのartifactId座標が、リポジトリ内のmavenアーティファクトの一意性に貢献しますが、Javaコード内ではないのですか？

例コード： Maven - Same Class Name Same GroupId Different ArtifactId

• Project1の最初のアーチファクトです。
• Project2は2番目のアーティファクトです。
• "Projects User"はProject1 & Project2の両方に依存するアーティファクト/プロジェクトです。
• Project1 & Project2のクラス名はUtilitiesです。
• クラスUtilitiesには、現在のプロジェクトのアーティファクト座標とプロジェクト名を含むstringを返すstaticメソッドpublic static String getDescription()があります。
• Utilities.getDescription()結果がStringとなり、エラーがどこかで発生するかどうかを確認し、解決方法を確認します。
• 出力は、「Projects User」成果物のpom.xmlファイルで最初に宣言された依存関係によって異なります。編集

：質問をフォローアップ

• ではなく、手動ですべての 時間をそれを行うために有するのでたartifactIdとのgroupIdの両方を使用してJavaパッケージを作成します原型はありますか？

Answer 1

この問題を解決/回避するベストプラクティスは何ですか？

moduleにgroupIdとartifactIdを基本パッケージとして含めます。この方法では、パッケージが異なるため、2つのモジュールで同じクラスを持つことはできません。

<groupId>net.openhft</groupId> 
<artifactId>chronicle-bytes</artifactId> 

は、パッケージの下にあるすべてのものを持っている

package net.openhft.chronicle.bytes; 

また、あなたは、あなたがどのJARそれがでなければなりません。

次の2つのJARファイルが必要なクラスを持っているかどうかを知るクラスのパッケージを知っていれば、私は、共通のモジュールを作成することをお勧めします。

注：あなたの会社のドメイン名（および概念上の部門も）をパッケージのベースとして使用するのが一般的です。 MavenはgroupIdとしてドメイン名を使用することをお勧めします.Maven Centralにリリースすると、これは現在の要件です。上記の戦略は両方の推奨事項をサポートしています。

なぜmavenのartifactId座標は、リポジトリ内のmavenアーティファクトの一意性に貢献しますが、Javaコード内ではないのですか？

MavenはJARの内容を通知しません。

Answer 2

@Peterこの問題を回避するためのベストプラクティスを推奨します。

1. グループID：プロジェクトを一意に識別する必要があります。あなたのドメイン名のrevese例： com.github.dibyaranjan
2. artifactIdはバージョンのないjarの名前です。

異なるJARから2つのクラスを区別するには、パッケージをgroupId.artifactIdとして作成します。

たとえば、私はプロジェクトTestDummyを作成します.JARの名前をTestDummy-1.1にして、私のパッケージは次のようになります。 https://maven.apache.org/guides/mini/guide-naming-conventions.html