A few months ago, we launched Insight Application Health Check. Today, I’d like to announce another way to get started tracking licensing and security issues. In this post, I’m going to show you how to scan your project with nothing more than Maven and an existing project. You can get started with Insight without having to download a client or server. All you’ll need to do is run a simple plugin from the commandline.
To enable users to scan their applications, we provide an executable JAR with a graphical user interface. With this interface users are a few clicks away from results. But, even with this GUI, some users want to be able to use Insight’s Application Health Check from the command-line because sometimes “clicking” isn’t the most effective way to get something done. If you’re building your application using Apache Maven, you probably already have a terminal window open to invoke its build phases. So, while you’re in there, adding or updating some dependencies in your POM and repackaging your application, why not check whether this dependency update introduced some security vulnerability or license issue, especially if it’s as easy as adding another goal to your command line? Meet the Application Health Check Maven Plugin:
mvn package com.sonatype.insight:ahc:run -D firstname.lastname@example.org
In Maven 3.0.3, we introduced some improvements to the way plugin goals can be configured. This post summarizes these improvements and gives some examples of how Maven plugin configuration has been enhanced. We’ve focused on making improvements that will reduce the friction of plugin configuration for both plugin developers and Maven end-users.
First, a general tip for users interested in using these enhancements in POMs: use the requireMavenVersion rule from the Maven Enforcer Plugin and required Maven version 3.0.3. This will save other team members from running into strange build failures due to plugin misconfiguration if they are still using previous Maven versions. Likewise, plugin authors that take advantage of these enhancements should properly declare the Maven prerequisite in the plugin POM.
In projects with many parent POMs, profiles, and plugin management sections, one can easily end up in a situation where the effective configuration for a plugin is the result of merging many configuration blocks from the various POM sources together.
Not knowing the details of this merge process naturally leads to some confusion about why an effective configuration looks the way it looks, or why changes to some parent POM’s configuration don’t have the desired effects in child POMs.
This post attempts to shed some light on this confusion, and provides you with a sense of how Maven merges plugin configuration from multiple sources. This post uses attributes which are available in Maven 3.0.2.
When developing plugins for Maven 3.0 plugin developers that need to perform dependency resolution have a choice: they can continue to use the Maven 2.x API, or they can use the new Maven 3 API which makes use of Aether. In this post, I’m going to walk through some of the API features that are now available to plugin developers in Aether.
If your plugin needs to be compatible with Maven 2.x, take a look at the sources of Maven Dependency Plugin. This example provides a sophisticated example of using the Maven 2.x dependency resolution API. But if legacy Maven support is of no concern to you, read on and see how the Maven 3.x API handles the job.
Asking the Maven issue tracker for all the changes or fixes that contribute to our freshly released Maven 3.0, one ends up with about 420 issues. While this is a rather large number, most of these issues deal with regressions we encountered and fixed during refactoring of the internals. But those issues are uninteresting to users that consider upgrading from Maven 2.x and want to know what’s the delta to 3.0.
The primary source of information for this delta are the compatibility notes and the plugin compatibility matrix. These documents focus on changes that could negatively affect existing builds due to stricter behavior of Maven 3.0, but we also managed to implement a few general improvements here and there.