web-dev-qa-db-ja.com

階層型複数モジュールプロジェクトのMaven命名規則

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

研究

尋ねる前に、私はこのトピックと私が自分でクリアしたことについて他のウェブを調べました：

  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レベルの階層とスプリングプレフィックスです。階層はそれほど深くないので、問題はありません。

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 Plugins は、最初は複数モジュールプロジェクト（org.Apache.mavenの後）であり、maven-compiler-plugin、maven-enforcer-pluginなどのアーティファクトがあります。

非常に多くの例があり、artifactId（したがってプロジェクトディレクトリ）の命名に関しては、すべて異なる規則に従います。

結果

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

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レベルの階層名は、root-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を使用するすべての人にとって大きな助けになります。ありがとうございました。

mavennaming-conventionshierarchydirectory-structuremulti-module
33
JMelnik

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)
20
khmarbaise

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

例えば。アーティファクトが名前で終わる場所と、競合が発生する可能性について答えようと思います。 springのようなフレームワークの場合、artifactId（ "spring- *"）にプロジェクト名を含めることは理にかなっていますが、commons-ライブラリにも同じことが言えます（ただし、 "commons-logging"は危険な名前である可能性があります）。

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

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

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

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

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

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

これが少し役に立ったことを願っています:)よろしく

wemu

4
wemu

別の可能なアプローチは、階層よりも機能グループを調べることです。

プロジェクトBにwebapps、プラグイン、コアライブラリがあり、すべてのモジュールが同じグループID（com.mycompany.b）を共有し、アーティファクトにそれぞれwebapp-???、plugin-???という名前が付けられているとします。とコア-???。

また、前述の-parent規則を使用します。したがって、すべてのwebappの親POMはwebapp-parent.pomと呼ばれます。

2
b75.