次のようにルートポンポンは別のファイル、ルートポンポン、ポンポンファイルのみ1つのプロジェクトファイルを作成します。
1.各ジャー依存バージョン、すなわち、コンテンツdependencyManagement
2.ビルドリソース要件とtestResourceファイル形式や保存先フォルダ
3. pluginManagement、各プラグインのバージョンを指定します
4. distributionManagement、PW所定のネクサス
II。それは3つのモジュールから構成され、プロジェクトファイルのプロジェクトmyprojectを作成します。
主モデルと列挙クラス情報に使用される1 MyProjectとモジュールは、他のサービスによって参照される必要が格納されています
2. MyProjectと-API、主にサービスインターフェースのサービスを格納するために使用
主にプロジェクトが提供するサービスを実装するために使用3. MyProjectとサービスは、実際の実現であります
だから、私はこのプロジェクトによ、4 POMファイルを取得し、たartifactIdは、myprojectにMyProjectとモジュールmyprojec-APIのmyprojecサービスでした
POMの継承：
最も外側のmyprojectに継承ルートポンポン、とmyprojectにモジュールmyprojec-APIのmyprojecサービスにプロジェクトmyprojectに三つのサブモジュールをそのバージョン番号を宣言し、親のポンポンがmyprojectにあり、彼らのgroupIdを継承しますが、たartifactId別々のモジュールとしてすべて、親POMサブモジュールバージョン番号から継承され、サブモジュールは、特定の瓶およびプロファイルに依存するために使用されるだけでなく、プラグインの様々な依存親POMバージョンから継承されます。
一部ふりAPIが実装されたに基づいてバネクラウドサービス管理フレームワークとして使用される特定の項目は、発信別ジャーを達成するため、所定のAPIで実装されたインタフェースとサービス、サービスインタフェースを実装漏れ、モジュールは、各露出外部で定義されていますカテゴリの定義。
より多くのエンジニアリング構造物を作るための理由：
各ジャーの1統一バージョン、技術的手法、サービスはよりAPIモジュールに統合されるため、各モジュールはバージョンから存在しジャー場合、最終的なバージョンは、特に特定の依存は、依存関係の問題を有することになる矛盾していますジャーセキュリティの問題、時間のバージョンアップが必要。
2.オリジナルの依存構造、APIのみを継承ポンポンを装う性質を持ち、サービスと独立した相続ポンポンはデシベルMVCユーレカ・クライアントのプロパティを持って、それぞれのポンポンが最終的に指定されたルートと実際の依存関係のさまざまなバージョンを継承ポンポン、ポンポンの様々な構成が、結果のバージョンで子供を簡素化することが面倒なアップグレードバージョンで、その結果、MavenのPOMの継承関係と相まって複雑、およびリリースに依存し、潜在的な競合ジャーがあります。
3. APIモジュールと更新サービス・インターフェースを有するバージョンは、により更新され、各サブモジュールの継承ので、インタフェースの更新のみPOMプロジェクトのバージョン発信バージョンに更新する必要が発生した場合、プロジェクトのバージョン番号。
