現在、1つのpom.xml（リンク）を使用して1つの「アーティファクト」を生成するプロジェクトがあります。
私がやりたいのは、プロジェクトを分割し、それをpと呼びましょう。
私がこれをやりたい理由は依存関係です。p-formatはそれらの70％以上をボリュームだけで取り込み、JSONスキーマの多くの使用はとにかくフォーマットのサポートを必要としません。
2つの完全に別個のプロジェクトをビルドする必要がありますか、それとも1つのpom.xmlを使用してこれら2つのアーティファクトを生成できますか？多くのプロジェクトがすでにそれを行っているので、後者は実行可能だと思います（たとえば、ジャクソン）。
[重要性がある場合は、SonatypeのMavenリポジトリを介して公開します]
2つの分離されたプロジェクト（2つの分離されたPOM）を作成する必要がありますが、モジュールとしてそれらを集約する共通の親を作成することをお勧めします。いくつかの基本については、POMの概要のプロジェクトの継承とプロジェクトの集約のセクションを参照してください。
Mavenでは、1つのPOMからさまざまなアーティファクトを生成するため、ハッキングを試みることは決して良い考えではありません。
p-formatをp-coreに依存する別のプロジェクトに単純に分割すると、作業がはるかに楽になります。
プロジェクトごとに複数のアーティファクトを公開する方法はありますが、Mavenはpom /モジュールごとに1つのアーティファクト（およびテストアーティファクト）を中心に設計されています。経験から、この設計ポイントを回避する巧妙な試みは、最終的にはあなたを噛むことになります-通常、パッケージングが誰かのマシンで適切に機能しない6か月後の問題の形で。
あなたが説明するシナリオは、マルチプロジェクトのユースケースにうまく適合します。フローに沿って、将来の自分を幸せにすることをお勧めします。
maven-assemblyプラグインを使用できます。2つのアーティファクトに重複するクラスがあり、一方を更新するには常にもう一方を更新する必要がある場合、これは適切な選択です。
アーティファクトのライフサイクルを考える必要があります。両方のアーティファクトは同じバージョン番号である必要がありますか？p-formatのバグを修正するたびに、新しいバージョンのp-coreを公開しますか？p-coreはそれ自体で役に立ちますか？
アセンブリプラグインは、主に同じアーティファクトに異なるパッケージを提供するために使用する必要があると思います。
私も同様のケースがあり、ミハルの提案に同意します。ただし、提案されたソリューションをさらに拡張したいと思います。
pには単一のソースがあり、p-coreとp-formatの両方がそこから生成されると想定しています。したがって、子モジュール（それぞれのPOMを含む）を使用してpの親POMを作成する必要があります。1つは「コア」用、もう1つは「フォーマット」用ですが、これらは両方とも親の/src/から取得します。
したがって、基本的に、「コア」と「フォーマット」のビルドプロセスを分離して特定のアーティファクトを生成しますが、pの元のソースを複製しません。
Mavenはこのアプローチをサポートしていますが、推奨していませんが、なぜそうすべきでないのかわかりません。私の意見では、その構造化された、クリーンで懸念は、長期的な影響なしに分離されており、これ以上の選択肢はありません。
http://maven.apache.org/guides/mini/guide-using-one-source-directory.html