<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

Sonatype Blog

Stay updated on the latest news from the makers of Nexus

John Casey

Recent Posts by John Casey:

Access Logging in Nexus 1.3.6

Since I've done much of the work on developing custom jetty.xml files for Nexus, it's probably natural that I was the one to research and answer the following question:

Maven 2.2.1 Released

I'm proud to announce the release of Apache Maven 2.2.1.

This release aims to fix some critical regressions introduced in Maven 2.2.0, along with some long-standing issues related to custom lifecycle configurations.

Addressing Regressions in the HTTP Wagon

Beginning in Maven 2.2.0, the default implementation of the HTTP Wagon was switched from the old Sun- / HttpURLConnection-based wagon to one that wraps HttpClient. This seemed to have several advantages, not least of which was giving the user more access to fine-grained configuration options and moving to a better-documented core API for Maven's most-used wagon. However, we soon realized that these improvements came with a hefty price tag.

Create a Customized Build Process in Maven

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.

Maven 2.2.0 Released!

I'm pleased to announce that we at the Apache Maven project have released Maven 2.2.0. You should definitely give it a spin! Maven 2.1.0 was probably the most stable release we've ever done, in terms of the number of reported regressions. Maven 2.2.0 improves on this stability by fixing the few critical bugs that did come up, along with adding some new functionality. You can grab the new version here.

Maven 2.1.0 Released

We’re pleased to announce the release of Maven 2.1.0. If you’ve been staring longingly at version 2.1.0-M1 for the last few months, but couldn’t quite get up the nerve to try a milestone release, here’s your chance! Version 2.1.0 builds on the unprecedented stability of 2.1.0-M1, fixing the one or two bugs that were found in that release and adding some exciting new features. Some of these features include:

The Hudson Build Farm Experience, Volume IV

In Progress: The Learning Curve We’re Still Climbing

Now that we’ve covered the high points of our Hudson build farm setup here at Sonatype, I want to discuss some of the current issues we’re facing at the moment. It’s important to realize that providing high-quality continuous integration is a long, involved process…not a quick, one-off event. Sure, you can get Hudson up and running fairly rapidly in a non-distributed environment. However, the path to distributed, multi-OS builds that capture a full range of testing can be very, very complex. In the end, if you can get by simply compensating for the problems I talked about in this series of posts, then you’re probably pretty lucky. Here at Sonatype, we’re certainly very conscious of the fact that our continuous integration setup could run more perfectly, and we continue to chip away at the list of things we’d like Hudson to verify automatically on our behalf. So, in the interests of full disclosure, I’m including a short wish list of items we’re currently working on.

The Hudson Build Farm Experience, Volume III

I’ve been working on a Hudson-based build farm for Sonatype and Maven open source builds since sometime in September of 2008. I’ve learned a lot as a result, so I thought I’d share some experiences from the trenches. In this third - and probably, final - installment I’ll discuss some issues we tackled with our VMWare environment itself, and look ahead to some issues with which we still grapple on a day-to-day basis.

VMWare, Efficiency, and the Space-Time Continuum

Compared to what we went through trying to get Windows builds running reliably out on the build farm, this discussion is going to seem somewhat…nitpicky. However, there are some important things to understand when you’re running a build farm on VMWare ESXi, so let’s dive in and take a look.