Develop Reference

Include git commit hash in jar version

I'm using maven and my goal is to include the git commit hash in the version number. Something like : 1.1.{git_hash}.
I'm trying to follow this tutorial.
Q: is it possible to somehow override the version number specified in the version element of the pom file?

One way to achieve this is to use the git-commit-id-plugin. Add this to the list of plugins in the build section of your pom.xml:
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>${git-commit-id-plugin.version}</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
<phase>validate</phase>
</execution>
</executions>
<configuration>
<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
</configuration>
</plugin>
Note, that I've changed the phase to validate, so the revision number property is already available in when the artifact is packaged.
Then, add the following to the build section:
<build>
<finalName>${project.artifactId}-${project.version}-${git.commit.id.describe-short}</finalName>
<!-- your list of plugins -->
</build>
The git.commit.id.describe-short property is produced by the git-commit-id-plugin. It contains current git revision number (shortened to 7 digits) and an optional dirty indicator.
The produced artifact will look like this: examplelib-1.0.2-efae3b9.jar (or examplelib-1.0.2-efae3b9-dirty.jar in case there are uncommitted changes on your repository).
Additionally, you might also want to put this information to the MANIFEST.MF of your artifact. In such case add this to your list of plugins (the example assumes the artifact is a jar):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<SCM-Revision>${git.commit.id.describe-short}</SCM-Revision>
</manifestEntries>
</archive>
</configuration>
</plugin>
Additional remarks:
I've shown a simple configuration of the git-commit-id-plugin. On their site you may find more options and properties. In addition to properties, that can be used inside pom.xml, the plugin can also generate a properties file containing information about revision.
As an alternative to git-commit-id-plugin, you might prefer buildnumber-maven-plugin. In order to get revision numbers this plugin requires a SCM plugin also configured in your pom.xml.
This setup may interfere with other plugins that transform or rename your artifacts (in my case it was the maven-shade-plugin - one of the sources jar it produces did not contain proper revision number).

The above accepted answer didn't work for me. I found the link https://dzone.com/articles/maven-git-commit-id-plugin, from where I copied the plugin code below. It worked first time for me. I now have the git.properties file automatically included in my target JAR file. Very useful for tracking.
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>2.2.4</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
</execution>
</executions>
<configuration>
<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
<prefix>git</prefix>
<verbose>false</verbose>
<generateGitPropertiesFile>true</generateGitPropertiesFile>
<generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>
<format>json</format>
<gitDescribe>
<skip>false</skip>
<always>false</always>
<dirty>-dirty</dirty>
</gitDescribe>
</configuration>
Add finalName to build section to also have the version in the target file name
<build>
<finalName>${project.artifactId}-${project.version}-${git.commit.id.describe-short}</finalName>
...
</build>

How can I speed up maven builds of JavaFX application?

My problem can be reproduced by creating a new project in Netbeans 8:
New Project >> Maven >> JavaFX Application
Then adding the org.springframework spring-context dependency.
Build times go up from a few seconds to more than half a minute, most of it due to running javafxpackager.
I can live with slow release builds but how can I speed up my development builds?
This is my pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org /2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>mavenproject1</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>mavenproject1</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<mainClass>com.mycompany.mavenproject1.MainApp</mainClass>
</properties>
<organization>
<!-- Used as the 'Vendor' for JNLP generation -->
<name>Your Organisation</name>
</organization>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<excludeScope>system</excludeScope>
<excludeGroupIds>junit,org.mockito,org.hamcrest</excludeGroupIds>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${java.home}/../bin/javafxpackager</executable>
<arguments>
<argument>-createjar</argument>
<argument>-nocss2bin</argument>
<argument>-appclass</argument>
<argument>${mainClass}</argument>
<argument>-srcdir</argument>
<argument>${project.build.directory}/classes</argument>
<argument>-outdir</argument>
<argument>${project.build.directory}</argument>
<argument>-outfile</argument>
<argument>${project.build.finalName}.jar</argument>
</arguments>
</configuration>
</execution>
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${java.home}/bin/java</executable>
<commandlineArgs>${runfx.args}</commandlineArgs>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<compilerArguments>
<bootclasspath>${sun.boot.class.path}${path.separator}${java.home}/lib/jfxrt.jar</bootclasspath>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>${java.home}/lib/jfxrt.jar</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.6.RELEASE</version>
</dependency>
</dependencies>
Thanks!
Daniel

You could define the plugin in a profile that is inactive by default. Then, in order to make the production build, you would have to manually specify the activation of that profile (or activate it in any other standard way).
You pom would be something like (only diffs shown):
<?xml version="1.0" encoding="UTF-8"?>
<project ...>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
...
<executions>
<!-- take this out of here
<execution>
<id>unpack-dependencies</id>
...
</execution>
-->
<execution>
...
</execution>
</executions>
</plugin>
...
</plugins>
</build>
<profiles>
<profile>
<id>javafxpackager</id>
<build>
<plugins>
<!-- INSERT THE exec-maven-plugin HERE, ONLY
WITH THE unpack-dependencies EXECUTION -->
</plugins>
</build>
</profile>
</profiles>
</project>
In production run mvn ... -Pjavafxpackager

To complete Nikos' answer, this is the configuration of the maven-assembly-plugin which creates the archive for normal builds.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<archive>
<manifest>
<mainClass>${mainClass}</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>my-assembly</id>
<phase>package</phase>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>

above solutions dont work. The problem has nothing to do with javafxpackager whatsoever. The cause lies in the maven standard configuration. On every project run Maven performs a project clean by default. This deletes the targets/classes/ folder. Thats the same folder where all the unpacked jar files of your dependencies are placed. If those get deleted on every new run then they have to be unpacked over and over again. Anyway, heres how you can prevent the clean from happening:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Add this to your POM.xml. Make sure you get the version correct You can check the version of your maven clean plugin in the effective pom (thats parent pom + project POM combined). In netbeans you can watch the readonly effective pom.xml under the effective tab when you've opened the pom.xml file of your project.
please give me a few +1's i want to get 50 points so that i can finally comment on other peoples answers. Thank you!
EDIT:
Also add skip to default-cli to avoid errors
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<skip>true</skip>
<executable>${java.home}/bin/java</executable>
<commandlineArgs>${runfx.args}</commandlineArgs>
</configuration>
</execution>
EDIT 2:
For those of you who would like to retain the ability to clean heres another method to prevent the maven plugin from deleting all jar files:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
<filesets>
<!-- delete directories that will be generated when you
start the develpment server/client in eclipse
-->
<fileset>
<directory>target/classes</directory>
<excludes>
<exclude>**/*</exclude>
</excludes>
</fileset>
</filesets>
</configuration>
Again, make sure is correct

TL;DR:
To avoid unpacking dependencies, you don't need to modify the default pom.xml at all. Just change what Netbeans calls when you press Run (or Debug). In nbactions.xml change:
runfx.args: Replace -jar "${project.build.directory}/${project.build.finalName}.jar" with -cp %classpath ${mainClass}. This way, the exec goal will not try to execute any jar but rather run your project from the target/classes directory. So no need to build the jar at all.
goals: replace the "package" goal with "process-classes" (or "test" or any phase you want). We don't need a jar so no need to run the package phase. And no package phase also means no unpacking/repacking etc.
If you ever need the jar file with all the dependencies, just choose "clean and build" in Netbeans or run mvn clean install.
Background:
What happens when you press run in the standard Netbeans JavaFX maven project is:
clean package exec - defined in nbactions.xml, configured in pom.xml:
clean: as usual - deletes the target directory
package:
first as usual - copies resources and compiles sources to target/classes and packs that all to a jar without dependencies
maven-dependency-plugin unpacks all the dependency jar files to target/classes
exec-maven-plugin:unpack-dependencies (the id "unpack-dependencies" is missleading, should be something like "jar-with-dependencies") executes javapackager which builds a jar with dependencies overwriting the first jar
exec:
executes java with ${runfx.args} as arguments (defined in nbactions.xml) i.e. runs the jar
What happens after the changes above:
clean process-classes exec - defined in nbactions.xml, configured in pom.xml:
clean: as usual - deletes the target directory
process-classes:
as usual - copies resources and compiles sources to target/classes
exec:
executes java with ${runfx.args} as arguments (defined in nbactions.xml) i.e. runs the class target/classes/path/to/your/MainClass
Even better:
You may want remove the "clean" goal from nbactions.xml. This way, all the resource files won't be copied each time over and over (although the resource plugin will still keep saying "Copying X resources" - see the comments under https://stackoverflow.com/a/33700970/3519572).
Now, you may also want to only recompile changed classes rather than the whole project by adding useIncrementalCompilation=false (e.g. like <goal>org.codehaus.mojo:exec-maven-plugin:1.2.1:exec -Dmaven.compiler.useIncrementalCompilation=false</goal>). But be sure to read https://stackoverflow.com/a/49700942/3519572!
Therefore, you may also want to add a toolbar button to the "clean" goal to be able to run it manually easily at any time: https://stackoverflow.com/a/26546551/3519572.
BTW:
Finally, you might want to change the NetBeans generated pom.xml anyway. At least my NB 8.2 refers to the deprecated javafxpackager (rename to javapackager). Also the part <bootclasspath>..../lib/jfxrt.jar</bootclasspath> doesn't seem to be necessary with java 8. It actually breaks my build if I run it from the terminal. Removing it seems to fix it and doesn't seem to cause any trouble if started from NB.

You can also use parallel maven build feature to speed up.
By default, Maven does not utilize the full power of your hardware. It builds all modules sequentially rather than in parallel. However, often your project setup does not require it to be sequential. Often you can command Maven to analyze your project including the dependency graph and build the project in parallel where possible. You can either specify the exact number of threads to use for building your project or use a portable version of the parameter and specify the number of thread in terms of CPUs available on the machine.
mvn -T 4 install -- will use 4 threads
mvn -T 1C install -- will use 1 thread per available CPU core
See for more details: https://zeroturnaround.com/rebellabs/your-maven-build-is-slow-speed-it-up/

Is there any way to change mywebapp-1.0-SNAPSHOT-classes.jar from attachClasses configuration in maven-war-plugin to mywebapp-1.0-SNAPSHOT.jar?

According to maven-war-plugin FAQ,
If you can't move the classes to another project, you can deploy the classes and resources included in your webapp as an "attached" artifact, with a classifier, by using the following configuration:
<project>
...
<artifactId>mywebapp</artifactId>
<version>1.0-SNAPSHOT</version>
...
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
This will result in two artifacts being deployed: mywebapp-1.0-SNAPSHOT.war and mywebapp-1.0-SNAPSHOT-classes.jar.
Is there any way possible that I could get mywebapp-1.0-SNAPSHOT.jar instead of mywebapp-1.0-SNAPSHOT-classes.jar?
Update: :
I want both war as well as jar to be generated. Though I am able to do this by applying profiles as mentioned in Changing packaging based on active profile in pom. But I am curious to know about above question.

Short answer: no, you can't.
By looking at the maven-war-plugin sources, in WarMojo.java (line 292), you can see that you cannot meet your requirement by simply modifying the maven-war-plugin configuration:
protected static File getTargetFile( File basedir, String finalName, String classifier, String type )
{
if ( classifier == null )
{
classifier = "";
}
else if ( classifier.trim().length() > 0 && !classifier.startsWith( "-" ) )
{
classifier = "-" + classifier;
}
return new File( basedir, finalName + classifier + "." + type );
}
Since the classesClassifier parameter is "classes" by default, you have no chance to modify this behavior: classifier will never be null.
Either you rename the file after its generation, or you modify the source code of the maven-war-plugin, and use it as a custom plugin.
As a final consideration, it is not advisable to have a null classesClassifier: it could be misleading. I do not know your project requirement though.
Hope it helps.

The closest approach to what you want to do is to use <classesClassifier>
as
<project>
...
<artifactId>mywebapp</artifactId>
<version>1.0-SNAPSHOT</version>
...
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<attachClasses>true</attachClasses>
<classesClassifier>someClassifier</classesClassifier>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
but this approach will always put the classifier as your_jar-classifier.jar and if you create and empty or spaced tag, it will default to -classes
On the other hand, by using archiveClasses instead of attachClasses you will find the JAR just as you want it inside war's WEB-INF\lib (without the classifier), but no WEB-INF\classes will be generated.

Try to configure your webapp's pom.xml using the following <build> section, to see if it fits your needs :
...
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>create-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>attach-jar</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}.jar</file>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
This section asks Maven to explicitly create a jar, then it attaches the created jar to the build so that the install phase can copy the generated artifact into the local repository.

<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>attach-jar</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}/WEB-INF/lib/${project.build.finalName}.jar</file>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Combining some of the ideas mentioned above seems to work for me. The <archiveClasses> (as explained here) causes the required JAR to be generated within the WAR file and the attach-artifact goal extracts that file as an artifact.

Maven's general philosophy is that one POM generates one artifact. That would mean the cleanest, most "Maveny" way to get the Jar out of your project is to separate your Java code and the Webapp items into two modules grouped together by a parent project.
So a potential project hierarchy could be:
mywebapp-parent/ -> Contains all dependency info, project version
mywebapp/ -> Creates Jar
mywebapp-web/ -> Depends on mywebapp, Creates War

Best way to convert existing java projects to osgi bundles

We have lot of components out of which we want to modularize only a few to start with. Wondering what is the best way (in the context of my build environment) to create bundles out of all these components?
My environment: Java 6, Maven 2.2.1, Hudson
Technologies: Spring 3.0.5, WebSphere 7, Hibernate 3.2.x and most of apache commons.
Requirements
Modularize only few components. Rest of the components can export all of the packages.
When imported into eclipse, I should be able to see the bundles of imported-packages as dependencies in build path (mvn eclipse:eclipse doesn't seem to do this)

Start by only changing the MANIFEST.MF entries such that all your artifacts become bundles - they obviously won't magically work but it's a good non-destructive first step.
When using the maven-bundle-plugin ensure you set extensions and supportedProjectTypes as you may have problems with CI builds, Maven repos and m2e failing if the packaging type is bundle (see end).
Test your riskiest/core external dependencies early on - for example if you're using JPA for persistence then ensure that the provider works in an OSGi environment with your domain bundle and JDBC driver.
If you're migrating from Java EE/spring look at Karaf or Virgo. But if your components are for embedded systems or have no external dependencies the Felix or Equinox may be enough (though check out the pax-url project if that's the case).
Might be worth editing your question to be a bit more specific about the domain/technologies?
eclipse:eclipse only generates that when the project is first configured, m2e's lifecycle problems might be a bit of pain but it's far better than using the old eclipse plug.
The following will add manifest entries to your existing artifacts without changing them in any other way. It tells the standard maven jar and war plugins to use the MANIFEST.MF generated by maven-bundle-plugin.
Put this in the parent POM:
<pluginManagement>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<extensions>true</extensions>
<configuration>
<archive>
<addMavenDescriptor>true</addMavenDescriptor>
</archive>
<supportedProjectTypes>
<supportedProjectType>jar</supportedProjectType>
<supportedProjectType>war</supportedProjectType>
</supportedProjectTypes>
<instructions>
<Built-By>${project.organization.name}</Built-By>
<Bundle-Vendor>${project.organization.name}</Bundle-Vendor>
<Bundle-ContactAddress>${project.organization.url}</Bundle-ContactAddress>
<Bundle-Description>${project.description}</Bundle-Description>
<Bundle-DocURL>${bundle.doc.url}</Bundle-DocURL>
<Bundle-Category>${bundle.category}</Bundle-Category>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Bundle-Version>${project.version}</Bundle-Version>
<Import-Package>*</Import-Package>
<Export-Package>*</Export-Package>
</instructions>
</configuration>
<executions>
<execution>
<id>bundle</id>
<goals>
<goal>manifest</goal>
</goals>
<phase>prepare-package</phase>
<inherited>true</inherited>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>create-war</id>
<phase>package</phase>
<goals>
<goal>war</goal>
</goals>
<inherited>true</inherited>
</execution>
</executions>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
</pluginManagement>
Then in child POMs, you may simply do:
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
</plugin>
<!-- Below is mutually exclusive: Either jar or war plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
</plugin>
</plugins>
</build>

Take a look at bndtools, it has excellent support for creating projects that wrap bundles. It provides a lot of insight how JARs are structured and how they depend on other things.

Use the maven bundle plugin. It will add the required import and export statements to you manifest based on scanning your code and the dependencies defined in the pom. This will require the least amount of effort to convert.
I also recommend you use M2Eclipse instead of mvn eclipse:eclipse. It will keep your maven config and workspace in sync.

How to run findbugs automatically in maven on install

It's easy to add the findbugs plugin to maven so that it will run if I do
mvn site
However, I would like it to run whenever I do
mvn install
just like unit tests. That is, I don't want the install to succeed if findbugs finds any bugs. Is there are way for me to do this?

About the findbugs:check goal, the documentation writes:
Fail the build if there were any FindBugs violations in the source code. An XML report is put out by default in the target directory with the errors. To see more documentation about FindBugs' options, please see the FindBugs Manual.
So this is precisely the goal you're looking for. You now just have to bind the check goal to the install verify phase (the verify phase occurs just before install and is actually made to run any checks to verify the package is valid and meets quality criteria so I think it's a better choice):
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.0.1</version>
<configuration>
<effort>Max</effort>
<threshold>Low</threshold>
<xmlOutput>true</xmlOutput>
</configuration>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
...
</project>
Of course, adapt the configuration to suit your needs.

<build>
<plugins>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.0</version>
<configuration>
...
</configuration>
</plugins>
</build>
findbugs:check goal
findbugs: Violation Checking