私は、mojo-executorを利用して他のmojoを呼び出す独自のプラグインを作成することになりました。これにより、1）ビルド構成を一元化し、2）各子プロジェクトで複製される構成の量を最小限に抑えることができます。
（このすべての理由に興味がある場合：各子プロジェクトはコマンドラインから実行されるジョブです。ビルドは呼び出し元のシェルスクリプトを設定し、それをビルドにアタッチして、アーティファクトにチェックインされるようにします。リポジトリ。デプロイスクリプトは、後でこれらを実行するマシンにプルダウンします。）
テンプレートプロジェクトのpomの関連部分：
<project ...>
<parent> ... </parent>
<artifactId>job-template</artifactId>
<packaging>pom</packaging>
<name>job project template</name>
<build>
<pluginManagement>
<plugin>
<groupId>...</groupId>
<artifactId>job-maven-plugin</artifactId>
<executions>
<execution>
<id>generate-sources-step</id>
<goals><goal>job-generate-sources</goal></goals>
</execution>
<execution>
<id>package-step</id>
<goals><goal>job-package</goal></goals>
</execution>
... (a couple more executions) ...
</executions>
</plugin>
</pluginManagement>
</build>
</project>
新しいmaven-pluginプロジェクト（job-maven-plugin）を作成する必要がありました。Pomは次のようになります：
<project ...>
<parent> ... </parent>
<artifactId>job-maven-plugin</artifactId>
<packaging>maven-plugin</packaging>
<name>job maven executor plugin</name>
<dependencies>
<dependency>
<groupId>org.twdata.maven</groupId>
<artifactId>mojo-executor</artifactId>
<!-- version 1.5 supports Maven 2, while version 2.0 only supports Maven 3 -->
<version>1.5</version>
</dependency>
</dependencies>
</project>
テンプレートプロジェクトからわかるように、プラグインには複数のmojoがありました（フェーズごとに1つ、何かが発生する必要がありました）。例として、ジョブパッケージmojoはパッケージフェーズにバインドされ、mojo-executorライブラリを使用して他の2つのmojo（ビルドアーティファクトをアタッチするだけ）を実行します。
/**
* @goal job-package
* @phase package
*/
public class PackageMojo extends AbstractMojo {
/**
* @parameter expression="${project}"
* @required
* @readonly
*/
protected MavenProject project;
/**
* @parameter expression="${session}"
* @required
* @readonly
*/
protected MavenSession session;
/**
* @component
* @required
*/
protected PluginManager pluginManager;
@Override
public void execute() throws MojoExecutionException, MojoFailureException {
ExecutionEnvironment environment = executionEnvironment(project, session, pluginManager);
// Attach script as a build artifact
executeMojo(
plugin(
groupId("org.codehaus.mojo"),
artifactId("build-helper-maven-plugin"),
version("1.7")
),
goal("attach-artifact"),
configuration(
element("artifacts",
element("artifact",
element("file", "${project.build.directory}/script.shl"),
element("type", "shl")
)
)
),
environment
);
// Zip up the jar and script as another build artifact
executeMojo(
plugin(
groupId("org.apache.maven.plugins"),
artifactId("maven-assembly-plugin"),
version("2.3")
),
goal("single"),
configuration(
element("descriptors",
element("descriptor", "${project.build.directory}/job/descriptor.xml")
)
),
environment
);
}
}
次に、子プロジェクトでは、プラグインを1回参照するだけです。私の意見では、これは、すべての子プロジェクトの舞台裏のプラグインのそれぞれを繰り返すよりも非常に望ましいです（これにより、pom間の結合が許容できないほど増加します）。将来、ビルドプロシージャにmojo実行を追加したい場合は、1つの場所を変更して、バージョン番号を上げるだけで済みます。子プロジェクトのpomは次のようになります。
<project ...>
<parent>
<groupId> ... </groupId>
<artifactId>job-template</artifactId>
<version> ... </version>
<relativePath>../job-template</relativePath>
</parent>
<artifactId>job-testjob</artifactId>
<name>test job</name>
<build>
<plugins>
<plugin>
<groupId> ... </groupId>
<artifactId>job-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
また、マルチモジュールディレクトリ構造全体は次のようになります。
+- job
+- job-core
+- job-maven-plugin
+- job-template
+- job-testjob1 (inherits from job-template)
+- job-testjob2 (inherits from job-template)
私の意見では、プラグイン構成がpomではなく一連のmojoに埋め込まれているため、このソリューションは完全に最適ではありませんが、構成を一元化し、子プロジェクトpom間の重複を最小限に抑えるという私の目標を満たしています。
（最後の注意： pomで複数のプラグインの実行をグループ化できるように見えるmaven-aggregate-pluginを発見しました。これにより、問題が少し望ましい方法で解決された可能性がありますが、最後のプラグインをやり直す気にはなりません。数時間の作業ですが、他の人にとっては有益かもしれません。）