33

階層ディレクトリ構造を持つ複数モジュール プロジェクトでの Maven 命名規則 (groupId、artifactId、およびディレクトリ名) について質問があります。

リサーチ

尋ねる前に、私はこのトピックについて他の Web を調べ、自分で解決したことを調べました。

  1. 私の質問は重複する可能性がありますが、複数の階層レベルはカバーしていません。

  2. プロジェクト ディレクトリ名は artificatId と一致する必要があります。

  3. 命名規則のガイドに は、例が示されています。

    • groupIdはすべてのプロジェクトでプロジェクトを一意に識別するため、命名スキーマを適用する必要があります。パッケージ名の規則に従う必要があります (例: org.apache.maven、org.apache.commons、org.apache.maven.plugins)。

    • artifactId作成した場合は、小文字を使用し、奇妙な記号を使用せずに、任意の名前を選択できます。(例: maven、commons-math)

これは非常に簡単で理解できますが、まだ不明な点がいくつかあります。

規約に記載されているartifactIdの例は、1 レベルの階層モジュールにのみ適用できます。

例

Maven リポジトリを調べて、いくつかの例を抽出しました。

Springは主に、spring-core、spring-context、spring-context-support という名前を使用します。スタンドアロン モジュールはすべて 1 レベルの階層であり、検索効率を高めるための spring- プレフィックスです。階層はそれほど深くないので問題ありません。

Apache CXFの命名は、Apache にとってはまったく型にはまらないものです。アーティファクトは、最大 5 つの異なるアーティファクトを名前に持つスタンドアロン モジュールです。cxf-tools-wsdlto-databinding-jaxb.

複数のモジュール プロジェクト (cxf-rt) にグループ化できる多くのアーティファクト (cxf-rt-databinding-jaxb、cxf-rt-databinding-aegis、cxf-rt-databinding-xmlbeans、cxf-rt-databinding-sdo) があります。 -databindings)、しかしそうではなかったため、名前はスパゲッティになりました。

最後に、Maven プラグインは、(org.apache.maven の後) 最初の複数モジュール プロジェクトであり、maven-compiler-plugin、maven-enforcer-plugin などのアーティファクトがあります。

非常に多くの例があり、artifactIds (結果としてプロジェクト ディレクトリ) の命名に関してすべてが異なる規則に従っています。

結果

例からベスト プラクティスを取り上げて、階層レベルを確認します。

1 レベルの階層の命名は (

groupId:    org.organization.project
artifactId: project-portal ---.
                              |
                              project-portal-service
                              |
                              project-portal-plugins (continued on next diagram)
                              |
                              project-portal-util

(続き) 2 レベルの階層は次のようになります。

groupId:    org.organization.project.plugins
artifactId: project-portal-plugins ---.
                                      |
                                      project-sample-plugin
                                      |
                                      project-another-great-plugin
                                      |
                                      ???? (multiple module project)

クエスチョンマークが見えますか？そこが

質問

例の規則に従いました (スパゲッティ Apache CXF の例は無視します)。

  • ルート - プロジェクト ポータル (例: spring-core、maven-core)
  • 第 1 レベルの階層名は、ルート - project-portal-plugins (例: spring-context-support) から継承します。
  • 第 2 レベルの階層名 - project-sample-plugin (例: maven-compiler-plugin)。

そして今、セーブやチェックポイントのない古いゲームのように、第 3 レベルで立ち往生しています。

  1. これは、より深い階層レベルの Maven の例から取得した正しいディレクトリ ネーミング パスですか?
  2. 単純なディレクトリ名とアーティファクト名をサポートし、より深いレベルでのスパゲッティ名を回避するために従う規則やルールはありますか?
  3. 単純な名前がある場合、groupId は重複したアーティファクト名 (単純さのために発生します) をリポジトリ内の競合から保存しますか?
  4. Web/リポジトリで名前が重複しているアーティファクトを検索して見つけることはどうですか (単純さのため)?

プロジェクト構造で、親の project-portal-liferay-plugins-themes のようなモジュールや、さらに悪いことに、子の project-portal-liferay-plugins-themes-white-puppy-wtf-name のようなモジュールを見たくありません。

上記の質問と考えられる問題のいずれかについて意見と実践を提供していただければ、私だけでなく、maven を使用しているすべての人にとっても大きな助けになります。ありがとうございました。

4

3 に答える 3

22

初期のmavenでは、あなたが説明した次の構造に従いました。

appname
  +--- appname-module1
  +--- appname-module2
              +--- appname-module2-chhild1
              +--- appname-module2-chhild2
  +--- appname-module3

しかし、レベルが上がると、これはばかげたことになります。

そこで、考えを変えることにし、今では次のようなものを使用しています。

appname
  +--- module1
  +--- module2
          +--- chhild1
                 +--- subchild1
          +--- chhild2
  +--- module3

レベルを通じて変更する唯一のものは、groupId です...

appname (groupId: com.soebes.appname)
  +--- module1 (groupId: com.soebes.appname.module1)
  +--- module2 (groupId: com.soebes.appname.module2)
          +--- chhild1 (groupId: com.soebes.appname.module1.child1)
          +--- chhild2 (groupId: com.soebes.appname.module1.child2)
  +--- module3 (groupId: com.soebes.appname.module3)
于 2012-02-27T07:49:43.423 に答える
5

この場合、プロジェクト構造をどのようにセットアップする必要があるかを明確に指定する規則はないと思います。

たとえば、アーティファクトが名前で終わる場所と、競合に遭遇する可能性について答えようとします。spring のようなフレームワークの場合、artifactId にプロジェクト名 (「spring-*」) を含めることは理にかなっています。commons-library についても同様です (ただし、「commons-logging」は危険な名前である可能性があります)。

スタンドアロンで実行するプロジェクトの場合、おそらくこれを行う必要はありません。しかし、多くの異なる jar が存在する liferay ポータルを使用するように見えるので、アーティファクトにプレフィックスを付けることをお勧めします。しかし、artifactId に基づいてプロジェクト構造を再構築しようとはしません。したがって、「project-modulename」は適切なモジュール名になります。jar はクラスパスを構築し、ビルド中に依存構造が定義されているため、これは問題ではありません。jar のリストに基づいて依存関係ツリーを再構築する必要がある場合: maven には META-INF に情報が含まれているため (リリースプラグインを使用している場合はこれもお勧めします)、そこから情報を取得できます。

モジュールを深くネストしないこともお勧めします。Eclipse にはこれに関するいくつかの問題があります (IntelliJ にはありませんが、Netbeans はネストされた構造もサポートしています)。

メインのポータル モジュールは、プラグイン モジュールに比べて頻繁に変更されることはありません。したがって、それらを別々のプロジェクトに分割することは理にかなっています-これにより、プロジェクトを別々にリリースすることもできます。

私にとっては、親モジュールに「-parent」サフィックスを付けて名前を付けることをお勧めします。これらのモジュールが依存関係として使用されることはめったになく、依存関係の「-parent」は何かが疑わしいことを示します。あなたが言ったように：artifacIdとモジュール名は同じでなければなりません。pom の名前として artifactId を使用することもお勧めします。一部のプラグインはここで違いを考慮しません。また、これらの値がすべて同じであれば、Eclipse の動作も向上します。

確かに、goupId と artifactId には重複した情報が含まれていることがよくあります (たとえば、その一部がプロジェクト名になります)。これが故意に行われたのか、過去数年間に起こったのか...? わかりませんが、このままにしておきます。アーティファクトは、GAV(P) 座標 (groupId、artifactId、バージョン、(パッケージ)) を使用して識別されます。groupId または artifactId に projectname アーティファクトが含まれている場合、アーティファクトが 1 つしかない場合は見つけやすくなります。

リポジトリ マネージャー (Nexus、Artifactory、Archiva など) を実行している場合、アーティファクトの検索は簡単です。多くの場合、検索では groupId/artifactId などがレンダリングされるため、「util」を検索すると、探しているアーティファクトを見つけるのに十分な情報が得られます。

これが少し役に立てば幸いです:)よろしく

ウェムー

于 2012-02-27T07:26:12.033 に答える
3

もう 1 つの可能なアプローチは、階層よりも関数グループを調べることです。

プロジェクト B に Web アプリケーション、プラグイン、およびコア ライブラリがあり、すべてのモジュールが同じグループ ID (com.mycompany.b) を共有し、アーティファクトはそれぞれ webapp-???、plugin-??? という名前になっているとします。そしてcore-???.

また、前述の -parent 規則も使用します。したがって、すべての Web アプリケーションの親 POM は webapp-parent.pom と呼ばれます。

于 2012-03-10T11:45:34.943 に答える