1に基づいて、再びプロジェクト構造を変更します
思考：
1.なぜですか。現在のパスレベルの親ポンポンのデフォルトパスです../
2. Mavenのモジュール、モジュールは、内部リンクの関数でなければならず、ルートPOMで参照三つのモジュールについての最初の記事は、その後のバージョンのアップグレードルートPOM、POM各モジュールが変更した原因となります問題
3.各サブPOM、独自の座標とバージョン情報を有し、それ自体継承POM少し違法
上記の3つの点を踏まえ、変更を行います。
1.プロジェクトがポンポン継承ルートポンポン、各サブモジュールは親ポンポンプロジェクトを継承し、モジュールの継承があるとして、そのような変更は、プロジェクトには影響しませんが、複数の継承構造,.ポンポンはバック設計変更へ直接渡さポンポン内のモジュール
2.各サブモジュールと独自のバージョンのgroupId情報を持っていないが、すべてのプロジェクトのPOMから継承されました
これらの変更後、
1.だけで、最新の層にポンポン修正版を働くルートポンポンは、アップグレードした場合ので、最小の変更
2. APIまたはモジュールおよびその他の関連する発行jarファイルはバージョン作られたバージョンをアップグレードするテーブルアクションのニーズが起こる場合には、再び、プロジェクトディレクトリに直接実行しました
MVNのバージョン：セット-DnewVersion = 1.0.1、バージョン（1.0.1または指定したバージョン番号）をアップグレードすることができ、アップグレードバージョンを確認することは正しいこと、継続
MVNのバージョン：コミットは、その後に変更をコミット
3.構造は、各サブモジュールは、一貫したエンジニアリングおよびPOMのgroupIdと一致するバージョンを維持します。
