Sonatype makes it easy to add your projects to the Central Repository with a free, public hosting service called OSSRH. We first blogged about this back in 2009, but given the growth in the community, we thought some of you may not have seen that post, so we decided to update it. Continue reading
Sonatype is going through the archives and digging up articles that we think would be useful to developers using our tools. If you use Maven, keep reading the post below from Sonatype Vice President of Engineering Brian Fox on Maven best practices and how-tos.
We have a handful of Maven best practice and how-tos documented in the blogs. Over time they get buried by newer posts, but the content is still just as relevant. Learn more about Maven by checking out the following blogs:
How to properly manage repository definitions and why you shouldn’t declare them in your poms.
How to most effectively create your own internal release of a snapshot dependency.
Multiple techniques for running Maven builds from a CI system.
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: Continue reading
Maven’s build process is driven by three key concepts: the build lifecycle, mojos, and the lifecycle mappings. If you’re not familiar with these concepts, you can read up on them in Maven, The Definitive Guide, especially Chapter 1 and Chapter 10.
Maven’s basic unit of work during the build is the Mojo (Maven POJO). Mojos are contained in plugins that group them together with similar functions. Additionally, Maven supplies a standard set of scaffolds – called build lifecycles – that provide an abstract, structured progression of the types of activities (lifecycle phases) typically found in a build. The standard build for a particular type of project is defined when the appropriate mojos are bound to the appropriate lifecycle phases using a lifecycle mapping.
Obviously, this is only a starting point; individual projects can further fine-tune their own builds by binding or reconfiguring mojos in their own POMs. However, the default build for a particular type of project – specified by the packaging element in the POM – is defined by its lifecycle mapping.
Maven provides mappings for many common project packagings out-of-the-box. But what if we have a custom project type? Maybe something that produces a particular type of artifact that only our internal systems know how to use? If we’re building a large number of these projects, it may make sense to teach Maven to support a custom project packaging. This is a relatively easy task, if you know a few tricks.
The Custom Lifecyle Mapping
In many cases, we’re interested in building a project artifact that is loosely based on the
jar archive layout, with some critical details such as files added to
META-INF/ that turn it into more than a run-of-the-mill classpath entry.
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)