maven


Define Maven plugins in parent pom, but only invoke plugins in child projects


I have a set of projects which all need to run the same series of Maven plugin executions during their builds. I'd like to avoid re-declaring all of this configuration in every project, so I made them all inherit from a parent pom "template" project which only contains those plugin executions (8 different mojos). But I want those plugin executions to only run on the child projects and not on the parent project during Maven builds.
I've tried to accomplish this four different ways, each with a side-effect I don't like.
Declare the plugin executions in the parent pom's build/plugins element and use properties-maven-plugin to turn on the skip properties on other plugins in the parent project. This didn't work because one of the plugin goals (maven-dependency-plugin:build-classpath) doesn't have a skip property.
Declare the plugin executions in the parent pom's build/pluginManagement element. Unfortunately this requires me to redeclare each of the eight plugins in the build/plugins element of every child project's pom like:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
...
This is too repetitive, and problematic if I ever need to change the plugins in the template pom.
Declare the plugin executions in a profile in the parent pom which is activated by the lack of a nobuild.txt file (which does exist in the parent pom, so the plugins don't execute there):
<profiles>
<profile>
<activation>
<file>
<missing>nobuild.txt</missing>
</file>
</activation>
<build>
....
</build>
</profile>
</profiles>
This works for the most part, except that the file path in the missing element seems to be based on the current working directory instead of the project basedir. This breaks some of the multimodule builds I'd like to be able to do. Edit: to clarify, the parent "template" project is actually itself a module in a multimodule project, and the build breaks when I try, for instance, to do a mvn install on the root. The project structure looks like:
+ job
|- job-core
|- job-template
|- job1 inherits from job-template
|- job2 inherits from job-template
Set up a custom lifecycle and packaging. This seems to allow me to bind plugins to lifecycle phases, but not specify any configuration.
So, is there another way to specify a bunch of Maven plugin executions that can be reused across several projects (with minimal repetition in each of those projects' poms)?
I ended up writing my own plugin which utilizes mojo-executor to invoke other mojos. This allows me to 1) centralize the build configuration and 2) minimize the amount of configuration that gets duplicated in each of the child projects.
(In case you are curious about the reason for all of this: each child project is a job which will be executed from the command line. The build sets up an invoker shell script and attaches it to the build so it gets checked into our artifact repository. A deploy script later pulls these down onto the machine they will run on.)
Relevant parts of the template project's 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>
Had to create a new maven-plugin project (job-maven-plugin). Pom looks like:
<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>
As you can see from the template project, there were multiple mojos in my plugin (one per phase that needed stuff to happen). As an example, the job-package mojo is bound to the package phase and uses the mojo-executor library to run two other mojos (which just attach some build artifacts):
/**
* #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
);
}
}
Then, in the child projects, I just have to refer to the plugin once. In my opinion, this is greatly preferable over reiterating each of the behind-the-scenes plugins in every child project (which unacceptably increases the coupling between poms). If I want to add a mojo execution to the build procedure in the future, I only have to modify one place and bump a version number. Child project's pom looks like:
<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>
Also, the entire multimodule directory structure now looks like this:
+- job
+- job-core
+- job-maven-plugin
+- job-template
+- job-testjob1 (inherits from job-template)
+- job-testjob2 (inherits from job-template)
In my opinion this solution is not entirely optimal, since I now have plugin configuration embedded in a series of mojos instead of a pom, but it meets my goals for centralizing the configuration and minimizing the duplication among child project poms.
(One last note: I just discovered maven-aggregate-plugin which seems to allow grouping multiple plugin executions in the pom. This might have solved the problem in a slightly more desirable way, but I'm not in the mood to redo the last few hours of work. Might be beneficial to someone else though.)
Personally I would go for solution 2. The repetition is minimal and you should try to avoid profiles if possible to avoid having to start documenting which profiles need to be activated for which projects.
A project should be able to be built correctly by simply doing a mvn (clean) install.

Related Links

locking snapshot versions when depending on multi-module project
Configure maven-war-plugin to include project classes in root of WAR
ShrinkWrap load libraries from POM for JavaArchive
Add log4j maven dependency to war without having it in compile time
Grails plugin installation
Building a previous version from svn
Bamboo: change the build root for maven plugin?
maven release plugin with phase and jar-with-dependencies
Failed to resolve dependency for wicket on jenkins and not on local machine
Java Build Tools: Ant vs. Maven [closed]
Maven build parameter to exclude a pom dependency
How to manage Tycho / EAP versionning correctly
Issue when injecting MavenProject into Maven test
Leiningen equivalent for maven dependency `type` element
Nexus Unable to connect with repos on the Internet
Excluding generated-sources from source:jar

Categories

HOME
bluetooth
omnet++
react-virtualized
relative-path
stock
onedrive
bpmn
cplex
sqlite-net-extensions
jira
dxl
ebean
indesign
constraint-programming
floating-action-button
modelica
etl
postgres-xl
gz
ibm-odm
visjs
paging
xlsxwriter
physics-engine
orleans
sylius
core-text
trading
chromebook
react-css-modules
filezilla
greendao
web-api-testing
fifo
dbclient
windowbuilder
google-rich-snippets
bosh
host
plsql-psp
hockeyapp
hilbert-curve
reportingservices-2005
midl
netcdf4
wptoolkit
qsslsocket
multipeer-connectivity
integrity
tropo
magma
libusb-win32
font-size
nsarray
jquery-filter
setuptools
slicknav
thrust
bluemix-app-scan
lemon
event-bubbling
composite
formatjs
operator-precedence
oxwall
knuth
id3v2
ceil
has-many-through
tld
starcluster
aapt
mechanize-ruby
ember-charts
message-driven-bean
mysqltuner
quantlib-swig
dexterity
runtime.exec
buster.js
qt-faststart
e4x
path-separator
jspinclude
yui-datatable
lpeg
radcombobox
blitz++
suppress
castle-monorail
thunderbird-lightning
firefox-5
substrings
backcolor
xetex
privilege
sustainable-pace
gacutil
windows-live-messenger
caching-application-block

Resources

Encrypt Message



code
soft
python
ios
c
html
jquery
cloud
mobile