私たちは、あなたがそれを何と呼ぼうとも、多くのモジュール/ピースを備えた複雑なプロジェクトを再構築することを計画しています。標準のディレクトリ構造に移行するために、Mavenファイル構造を採用したいと思います。
したがって、大きな問題は、Mavenのファイル構造の説明を誰かが提供できるかどうかです。ここでは、Mavenが話すすべてを掘り下げる必要はありません。
私たちは、あなたがそれを何と呼ぼうとも、多くのモジュール/ピースを備えた複雑なプロジェクトを再構築することを計画しています。標準のディレクトリ構造に移行するために、Mavenファイル構造を採用したいと思います。
したがって、大きな問題は、Mavenのファイル構造の説明を誰かが提供できるかどうかです。ここでは、Mavenが話すすべてを掘り下げる必要はありません。
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.htmlを参照して ください
src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
README.txt Project's readme
ところで、既存のプロジェクトでその移行を行いました。すべてを意図したとおりに機能させるのは非常に長く困難な作業でしたが、ようやく完了し、満足しています。
更新しました
多くのプロジェクトがある場合、プロジェクトごとに同じ構造になります。
今、あなたがそれらをグループ化したいときに本当の問題が始まります。Mavenのドキュメントとベストプラクティスを読み、適切な構造を決定するのに苦労しました。
基本的な考え方は、関連するプロジェクトを共通のディレクトリ(モジュールと呼びます)にグループ化し、モジュールをリストせずにモジュール全体を処理できるようにすることです。ただし、モジュールをIDE(この場合はEclipse)で開くと、プロジェクト自体はそのモジュールに属しますが、サブプロジェクトとしては開かれません(その概念はEclipseには存在しません)。
最終的には厳密な階層になり、多くのMavenの問題から解放されました。
私は、Maven2.2.1とMaven3.0-alpha-6の両方で、多くのプロジェクトでJensと同じアプローチを使用してきました。POMモジュールはプロジェクトツリーのモジュール構造を定義し、JAR/WARモジュールは木。すべてのモジュールのバージョンは同じです。
利点:
短所: