In projects with many parent POMs, profiles, and plugin management sections, one can easily end up in a situation where the effective configuration for a plugin is the result of merging many configuration blocks from the various POM sources together. Not knowing the details of this merge process naturally leads to some confusion about why […]
One of the key things driving the adoption of Maven, is the rich set of plugins available. Whenever you want to add some functionality to the build process, or possibly even just want to do a one-time job, chances are that there is already a plugin for that. When you want to use Maven plugins, you […]
One of the key things driving the adoption of Maven, is the rich set of plugins available. Whenever you want to add some functionality to the build process, or possibly even just want to do a one-time job, chances are that there is already a plugin for that. When you want to use Maven plugins, […]
It’s been a while since I posted, so here’s a quick and dirty code by example: If you want to make a standalone jar (ie one with no dependencies) executable, here’s how you do it:
With it’s default behavior, Maven runs a plugin invocation for each project in a multi-module build. For plugins that operate on a single project at a time, this is what the author wants.
Some plugins are what we call “aggregators” which means they actually do want all the information about the full multi-module build before execution. These plugins, when run on a tree of projects cause Maven to resolve all the children before calling the plugin’s execute() method. In this mode a plugin executes just once, but effectively on the whole tree at once. (as a side note, you never want to bind an aggregator goal in your pom as this would cause the plugin to run an n! recursive build since the lifecycle would step into each child and execute the aggregator…which would cause Maven to reresolve all the children, etc)
Sometimes neither of those behaviors are what you want.
Anders Nawroth of the Neo4J project asked an interesting question on the neo4j-user list: What’s the best option when deploying neo4j code examples using Maven? It’s really not of any interest to deploy the artifact itself, it’s the sources (if possible with some exclusion of resources) that we want. Anders’ requirements: create a project which […]
Maven has two sections in the pom relating to plugin configuration: project.build.plugins and project.build.pluginManagment.plugins. These two sections are unfortunately often confused and misused.
Maven 2.0.9 introduced the ability to override a dependency used by a plugin. This is handy when you want to use a newer checkstyle, pmd, etc jar than is included by default in the plugin. How you go about doing this actually depends on your use case because of an oversight in the Maven 4.0.0 […]
Maven 2.0.9 was released today. I previously blogged about the changes to the process that will hopefully lead to more stable releases in the future. Today I want to talk about some important changes in the release itself that improve the user experience a bit. Probably the biggest and most anticipated change is the shift […]