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 packages itself, wire the appropriate goal into the lifecycle. He’s headed in the right direction, the Maven Assembly Plugin, but he might not know about the pre-defined assembly descriptors as they are somewhat hidden on the Apache Maven site. Since other projects might have similar requirements, here’s a quick explanation of all the moving parts…
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 model used by the Maven 2.0.x versions.
If you are using a plugin as a normal build plugin (as opposed to a report) then you will have it bound similar to this:
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 towards specifying default versions for the core set of plugins. Before I go further, lets have a background lesson on how Maven handles the plugins and why this was a pain point for some users.