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.

Read more…

Sonatype Maven, Maven 3, Sonar

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.

Read more…

Maven, Sonatype Maven, 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. Read more…

Nexus, Sonatype Community, Nexus, plugins, security

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!

The first issue was from the mailing list, where building a multi-module project involving a SAR archive did not work when building just to the package phase. I am guessing here somewhat, but I think the problem lay in the reactor in combination with a build extension packaging (for the SAR archive).

The second case was something I ran into when building a two-level multi-module project including a Java EE 5 EAR archive, which had a lib directory specified. Also, a workaround with a ‘client’ type classifier was used to get a ejb-client jar to be placed in the lib directory (MEAR-85). When building from the EAR project or one level above, it worked just fine and the ejb-client JAR was placed in the lib directory. But when built from the top level, the lib directory specified was ignored and the ejb-client JAR was placed in the root of the EAR.

Both issues existed with Maven 2.2.1, but not with Maven 3.0-alpha-3 and 3.0-alpha-4 respectively. And now 3.0-alpha-5 is out, with an even more improved formula. Don’t let the alpha name fool you, to my experience it is the best Maven ever. If you run into some issue with Maven 2.x, be sure to try out the latest Maven 3.0-alpha – I wouldn’t be surprised if it solves your problem!

Maven Devoteam, Maven

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.

Read more…

How-To, Maven Devoteam, Maven