<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

Anders Hammar

Recent Posts by Anders Hammar:

Top Ten Reasons to Move to Maven 3

I recently helped Dennis Lundberg prepare a talk for Jfokus on the top reasons why you should switch to Maven 3. When I work with customers setting up, or improving, their Maven-based development infrastructure I always recommend using Maven 3. I thought I'd share with you the top ten reasons that Dennis highlighted in his talk.

In a nutshell, Maven 3 is superior to Maven 2. While there might not be one single killer feature for most users, it's more a matter of several bug fixes and improvements that together make it a much better tool. Depending on your use case and your preference, some of these reasons will be more compelling than others. Here's the list.

#1. Maven 3 is the "Latest and Greatest"

Surely not the wording that you should use when selling this to your manager/boss/product owner/whatever, but when it comes to tools and frameworks many developers like knowing they are using the latest version. Maven 3.0 is where all the new work is done and where the main focus is. Maven 3 has a six week release cycle which was inspired by how things work at Eclipse. This gives you more predictability. You know that critical and serious bugs will be addressed quickly, and you'll only need to wait a few weeks before the next official release is available.

Retrieving a plugin's documentation

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 need to get more information about them to know how to use them. Most often, there is online documentation that describes the goals and parameters. However, sometimes no such documentation exists or you just cannot find it. Also, the online documentation very often describes the latest version of the plugin - but what if you have to use an older version?

This blog post will explain the different options you have to retrieve information about a plugin, just by using Maven itself.

Maven 3 and Sonar

Another step towards a final release of Maven 3.0 was made the other day when version 3.0-beta-2 was released. I’ve been using Maven 3 since its alpha days, and despite the alpha/beta moniker, I find it to be superior to any Maven 2.x version. If you are starting a new project, I strongly recommend using Maven 3.

That being said, in the complete development environment there are a few missing pieces when working with Maven 3. One of these is getting Sonar to work with Maven 3, which had not been possible until the latest version of Sonar was released.

This post will explain how to get Maven 3 and Sonar to work together.

DIY: Retrieving a Maven plugin's documentation

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 need to get more information about them to know how to use them. Most often, there is on-line documentation that describes the goals and parameters. However, sometimes no such documentation exists or you just cannot find it. Also, the on-line documentation very often describes the latest version of the plugin - what if you have to use an older version?

I recently faced a closed-source plugin, with no documentation. This blog post will explain the different options you have to retrieve information about a plugin, just by using Maven itself.

As mentioned above, the simplest way of viewing a plugin's documentation is to use the one provided on-line. Normally in HTML and created by the Maven Site Plugin, this is what we have got used to with most open source plugins.

Not only does this documentation describe the available goals and its parameters, but it most often also provides examples and other useful information. If available, this should normally be your first choice. However, there are at least two other ways of retrieving information from a plugin about it's goals and parameters. These come in handy when there is no other documentation, but also when you want to be sure to find the goals and parameters of a specific version of the plugin.

Meet the Nexus Remote Repository Browsing Plugin

Having used Nexus since it was a beta release and having also written a Plexus component-style Nexus plugin (the nexus-ldap realm), I was curious about the new Nexus Plugin API introduced in Nexus 1.4.0. To try it out, I asked two of our developers here at Devoteam Sweden to develop the Nexus Remote Repository Browsing Plugin - a Nexus plugin that makes it possible to directly browse the remote Maven repository of a proxy repository within the Nexus UI. The plugin has been contributed to Nexus OSS and will be released as a part of the upcoming 1.5.0 release. In this blog post, I will talk a little bit about the plugin and its use case.

Maven 3.0 - New and Improved Formula

During all the years that I've been using Maven I haven't run into any issues that were caused by a bug in the Maven core. Issues which I know of, I should add. I might just have been lucky or possibly I have run into a bug but blamed it on some plugin. However, during the last couple of weeks I've been running into two bugs in the Maven 2 core. They were both a kind of an edge case, but when built with Maven 3.0-alpha everything worked!

Special Character Encoding Properties

The other week I listened to Dennis Lundberg's presentation "Site creation with Maven" and learned something new. As most of us living outside the plain ASCII world have experienced, character encoding makes a big difference when it comes to ensuring that text remains readable. For XML files, the encoding can be defined through the XML header which makes it possible for an XML file reader to decide on the proper encoding. But for other types of files such as Java source files and properties files, the encoding has to be defined outside of the actual source file.

Even though encoding seems to be handled correctly in your environment, with your local language settings or some implicit default value, the best practice is to always explicitly define the character encoding. This will make sure that your build is portable and it will also protect you in the future in case some of your default values change. The bottom line is, just do it!

In the Maven world, you need to specify the character encoding for every plugin that processes source files or creates reports. It would have been great if this were made possible through a shared configuration element in the POM, but that would require an update to the POM model and that won't happen until Maven 3.x. In the meantime, two special properties have been defined.