I'm getting an unexpected version of a dependency (1.5.8) when I use the assembly plugin, but nowhere else. In my pom I have:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.0</version>
</dependency>
When I run dependency:tree or dependency:list, I see the correct version and only the correct version. When I check in Eclipse I see only the correct version.
In my assembly.xml I have:
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
</dependencySet>
</dependencySets>
In the resulting zip, I get slf4j-log4j12-1.5.8.jar. No idea where this is coming from. Any help?
Using maven 3.0.4.
This was due to a 'bad' assembly plugin version (2.2-beta-5). My pom.xml did not specify the plugin version. When I explicitly marked it as 2.4 (or the latest version when you read this!), the plugin pulled the correct dependency.
Lesson learned - If you get the following warning in your build:
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-whatever-plugin is missing
It is highly recommended to fix these problems because they threaten the stability of your build.
.. fix it!
You may try to delete the bad JAR (slf4j-log4j12-1.5.8.jar) from your maven repository and add the correct one there (slf4j-log4j12-1.6.0.jar). Then run your build with the --offline switch. In the moment that maven tries to get the wrong JAR, the build will fail and maven will show you from what transitive dependency it is trying to get it. Then you exclude it from the transistive dependencies with this:
<exclusions>
<exclusion>
<artifactId>slf4j-api</artifactId>
<groupId>slf4j-log4j12</groupId>
</exclusion>
</exclusions>
Check if it the JAR that you got has the correct groupId. Some people creates duplicates of common JARs for stupid and evil special purposes that may confuse maven. In special, check if you are not getting org.jboss.resteasy:slf4j-log4j12 instead. You may ban undesired dependencies using the maven-enforcer-plugin, like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>enforce-banned-dependencies</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.slf4j:slf4j-log4j12:1.5.8</exclude> <!-- Wrong version, dude! -->
<exclude>commons-logging:*</exclude> <!-- Worst, stupidest, lamest logging framework ever! -->
<exclude>org.jboss.resteasy:slf4j-simple</exclude> <!-- Evil JAR duplication. -->
<exclude>org.jboss.resteasy:slf4j-api</exclude> <!-- Evil JAR duplication. -->
<exclude>org.jboss.resteasy:slf4j-log4j12</exclude> <!-- Evil JAR duplication. -->
<exclude>org.jboss.resteasy:jackson-core-asl</exclude> <!-- Evil JAR duplication. -->
<exclude>org.jboss.resteasy:jackson-mapper-asl</exclude> <!-- Evil JAR duplication. -->
<exclude>org.jboss.resteasy:jackson-core-lgpl</exclude> <!-- Evil JAR duplication. -->
<exclude>org.jboss.resteasy:jackson-mapper-lgpl</exclude> <!-- Evil JAR duplication. -->
<exclude>org.codehaus.jackson:jackson-core-lgpl</exclude> <!-- Two distinct packages for the exact same thing always creates conflicts. We want the ASL one. -->
<exclude>org.codehaus.jackson:jackson-mapper-lgpl</exclude> <!-- Two distinct packages for the exact same thing always creates conflicts. We want the ASL one. -->
<exclude>velocity-tools:velocity-tools</exclude> <!-- Was renamed. -->
<exclude>velocity:velocity</exclude> <!-- Was renamed. -->
<exclude>struts:struts</exclude> <!-- Was renamed. -->
<exclude>javassist:javassist</exclude> <!-- Was renamed. -->
<exclude>axis:*</exclude> <!-- Was renamed to org.apache.axis:* and wsdl4j:wsdl4j . -->
<exclude>commons-beanutils:commons-beanutils-core</exclude> <!-- Redundant package. -->
<exclude>xpp3:xpp3_min</exclude> <!-- Redundant package. -->
<exclude>xml-apis:xml-apis:2.0.0</exclude> <!-- Bad package, for some strange reason 2.0.x is inferior to 1.4.x. -->
<exclude>xml-apis:xml-apis:2.0.2</exclude> <!-- Bad package, for some strange reason 2.0.x is inferior to 1.4.x. -->
<exclude>quartz:quartz</exclude> <!-- Was renamed. -->
</excludes>
</bannedDependencies>
</rules>
</configuration>
</execution>
</executions>
</plugin>
Related
I am just trying to pickup with maven-enforcer-plugin using a small pom (before I jump in to my project pom which has 100+ dependencies.)
After I have added the enforcer plugin, I am seeing Dependency convergence error.
The pom.xml file is below (sorry its not tidy).
How can i fix the errors with out disabling the enforcer plugin.
Basically I want to understand the concept behind how to use dependencyConvergence rule.
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.demo</groupId>
<artifactId>enforcer</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<!--
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>5.2.13.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>5.2.13.RELEASE</version>
</dependency>
-->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.2.10.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.3.5</version>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>5.4.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0-M3</version>
<executions>
<execution>
<id>dependency-convergence</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<dependencyConvergence/>
</rules>
</configuration>
</execution>
</executions>
<configuration>
<rules>
<dependencyConvergence />
</rules>
</configuration>
</plugin>
</plugins>
</build>
</project>
Does it mean that, I have to declare each non converging dependency in the dependencyManagement explicitly as in this version of pom.xml(added dependencies to dependencyManagement).
The problem with spring-context still exists as I have added it as direct dependency and then in the dependency management with different version.
Basically - am able to fix the error, but not able to grasp the rules crystal clear yet.
fix one - pom.xml - updated the version in dependency management to the one used explicitly. So now there is no need to give the version explicitly in dependencies. But this would require me to have access to dependencyManagment of parent pom. If my statement is right, this might not be the situation every time.
fix two pom.xml - excluded spring-context from spring-security-web and it worked. But if there are a dozen of exclusion to be done, its going to be a pain.
If this is the way to go about with the convergence rule? In an enterprise project with 100+ dependencies and 100+ of their transitive dependencies, then the Bill of Materials(BOM) is gonna be quite huge and take time to build. hhhmmm. (I agree, there is going to be more control over the versions used and using property like <xyz.version>, upgrades can be done easily).
I will very much appreciate if anyone can list down the rules involving convergence.
A dependency convergence error means that
the dependency is not in dependencyManagement
there are different versions of the dependency in the dependency tree
The typical resolution is to define an entry in dependencyManagement that resolves the issue or to import an appropriate BOM into the dependencyManagement.
This is best done in the main POM of a multi module project, but also possible in modules.
Note that it is better to leave out the <version> tag in the <dependencies> section so that dependencyManagement will be used everywhere.
Here is the project i'm working on: https://github.com/veracityidinc/idf-sandbox
I'm a front end dev so this is all a bit unclear to me.
I looked at the build log to try to figure after of course consulting google, and i see people saying stuff about a plugin and copying files. It just seems very weird to me that a web project - be it whatever kind - doesn't do this out of the box. It is very tedious to have to close and run the server any time i make a change. Also very weird that the html part of the app actually does this on its own.
GWT only deals with JS (and assets directly loaded by the code through special code constructs), not the other web assets.
DevMode (mvn gwt:run with Mojo's plugin) will serve your webapp, and Mojo's plugin will additionally copy the src/main/webapp on launch. If you want to update your web assets without restarting the DevMode, run mvn war:exploded -Dgwt.compiler.skip. And similarly for resources (in src/main/resources): run mvn process-resources.
This is also one good reason to adopt a different project layout, separating client and server code into distinct Maven modules, and running client and server code separately too (mvn gwt:codeserver for client code, through the net.ltgt.gwt.maven:gwt-maven-plugin, and mvn jetty:run or similarly for server code and web assets)
Using GWT SDM -Super dev mode- you will get this out of box, the SDM will keep running i the background and watch for files modified and upon refresh it will incrementally recompile your app and reload resources.
if you are using maven to get SDM to work you need to create a GWT project and apply the maven plugin, the recommended plugin is the tbroyer plugin and to create a GWT project that already configured correctly out of the box you can use the tbroyer multi module gwt-maven-archetype.
following the instructions from the archetype when you issue the command
mvn gwt:codeserver -pl *-client -am you are actually starting the SDM. the other command is starting your application server.
the generated project has a xxx-server module in which you can find a css file. once you run both commands and can load your application in the browser try to change some styles in that file and refresh the page, the changes should be reflected.
this is a sample plugin configuration when generating a project from the archtype
<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<configuration>
<moduleName>[replace this with your module]</moduleName>
<moduleShortName>app</moduleShortName>
</configuration>
</plugin>
now if you are not using this multi module structure you might try the start the application and the SDM using mvn gwt:devmode this should start the SDM for you
and if you are using uibinder, and you are editing styles in the *.ui.xml files when the SDM recompiles it should also pick the changes.
Edit
Checking on your project i made some changes to make it work.
first i changed the pom.xml, you can use my version for later projects but i think the better way is the generate a project using tbroyer archetype
The pom
<?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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.candorgrc.idfusion</groupId>
<artifactId>idf-sandbox</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>IdFusion™ Sandbox</name>
<properties>
<!-- Setting maven.compiler.source to something different to 1.8 needs
that you configure the sourceLevel in gwt-maven-plugin since GWT compiler
2.8 requires 1.8 (see gwt-maven-plugin block below) -->
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<inject.gin.version>2.1.2</inject.gin.version>
<inject.guice.version>3.0</inject.guice.version>
<libsass.version>0.2.10-libsass_3.5.3</libsass.version>
<lesscss.version>1.7.0.1.1</lesscss.version>
<elemental2.version>1.0.0-RC1</elemental2.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt</artifactId>
<version>2.8.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-servlet</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.elemental2</groupId>
<artifactId>elemental2-dom</artifactId>
<version>${elemental2.version}</version>
</dependency>
<dependency>
<groupId>com.google.gwt.inject</groupId>
<artifactId>gin</artifactId>
<version>${inject.gin.version}</version>
</dependency>
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>${inject.guice.version}</version>
</dependency>
</dependencies>
<build>
<!-- Output classes directly into the webapp, so that IDEs and "mvn process-classes"
update them in DevMode -->
<outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/classes</outputDirectory>
<plugins>
<!-- GWT Maven Plugin -->
<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.0-rc-8</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<configuration>
<moduleName>com.candorgrc.idfusion.sandbox.IdfSandbox</moduleName>
<moduleShortName>IdfSandbox</moduleShortName>
<failOnError>true</failOnError>
<!-- GWT compiler 2.8 requires 1.8, hence define sourceLevel here if
you use a different source language for java compilation -->
<sourceLevel>1.8</sourceLevel>
<warDir>${project.build.directory}/${project.build.finalName}</warDir>
<classpathScope>compile+runtime</classpathScope>
<!-- URL(s) that should be opened by DevMode (gwt:devmode). -->
<startupUrls>
<startupUrl>sandbox.html</startupUrl>
</startupUrls>
</configuration>
</plugin>
<plugin>
<groupId>org.lesscss</groupId>
<artifactId>lesscss-maven-plugin</artifactId>
<version>${lesscss.version}</version>
<configuration>
<sourceDirectory>${project.basedir}/src/main/webapp/less</sourceDirectory>
<outputDirectory>${project.basedir}/src/main/webapp/less</outputDirectory>
<compress>true</compress>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
you will also need to create a new package on the same level as the client package and name it public this is the default public resource used by gwt. this should go in the src folder com.candorgrc.idfusion.sandbox.public then move your css file sandbox.css into this package.
once you do these changes you will be able to reload the css when you refresh the page as long as your IDE knows that the css is changed and it should move it to the correct location in the target folder.
I'm using the maven-shade-plugin to create an executable jar that contains all of my project's dependencies. Sometimes, these dependencies bring in dependencies of their own that clash with the dependencies of other libraries, and the maven-shade-plugin warns me that it isn't sure which version to include in the uber jar.
[WARNING] maven-shade-plugin has detected that some .class files
[WARNING] are present in two or more JARs. When this happens, only
[WARNING] one single version of the class is copied in the uberjar.
[WARNING] Usually this is not harmful and you can skeep these
[WARNING] warnings, otherwise try to manually exclude artifacts
[WARNING] based on mvn dependency:tree -Ddetail=true and the above
[WARNING] output
In general, my response to this warning is to use the <exclusions> element of the dependency declaration in my pom file to remove the offending dependencies from my project:
<!-- Amazon ElastiCache Client -->
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>elasticache-java-cluster-client</artifactId>
<version>1.0.61.0</version>
<exclusions>
<!-- this junit dependency clashes with our test-scoped one and causes integration tests to fail to run -->
<exclusion>
<groupId>junit</groupId>
<artifactId>junit-dep</artifactId>
</exclusion>
<!-- this dependency brings in two versions of cglib that clash with one another -->
<exclusion>
<groupId>jmock</groupId>
<artifactId>jmock-cglib</artifactId>
</exclusion>
<!-- newer versions of these dependencies come with dropwizard-core -->
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
When I do this, I use mvn dependency:tree to make sure that I'm excluding the lower version of the offending dependency, in hopes that the newest version is the most mature and bug free.
Cases like the one above that end up with a lot of exclusions raise two questions about this practice:
In the example above, why do I have to manually exclude junit and jmock? Both of these dependencies are marked as <scope>test</scope> in the elasticache-java-cluster-client pom.xml, so I would expect that they wouldn't be included in the jar that I get from maven.
While my practice of always taking the newer version of a dependency seems to have worked so far, I'm afraid that one of these days I'm going to break something. Is there a better way to determine which version of an dependency to keep?
Have you tried adding the maven-enforcer-plugin with the DependencyConvergence rule? This worked well for me in combination with the shade plugin. It will tell you which artifacts are bringing in different versions of the same classes. It allowed me to find out what I have to exclude.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce</id>
<configuration>
<rules>
<DependencyConvergence/>
</rules>
</configuration>
<goals>
<goal>enforce</goal>
</goals>
</execution>
</executions>
</plugin>
I have an external .jar that cannot be imported from public repositories using pom.xml, it's sqljdbc41.jar.
I can run the project locally from my IDE, and everything will work. I referenced the library after downloading it like so:
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc41</artifactId>
<version>4.1</version>
<scope>system</scope>
<systemPath>${basedir}/lib/sqljdbc41.jar</systemPath>
</dependency>
When I run mvn clean package to create my .jar file and try to run the created .jar, a mistake will pop up, which mentions the SQL Server references are not valid. I then extracted my .jar file and true enough, everything that is referenced in the pom.xml file properly gets downloaded and added, however, my SQL Server does not.
I can, in a very hacky way* just manually add the sqljdbc41.jar to my /lib folder after it's been compiled as a .jar, and it'll work, however that seems highly unoptimal. What would be a better approach?
*Opening the .jar file with Winrar, going to the /lib folder, manually selecting my sqljdbc41.jar file, then make sure to select the No Compression option bottom left where Winrar gives you compression options, in case you find this by Google and no one answered.
you can set 'includeSystemScope' to true.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
You could install the sqljdbc41.jar in your local repository :
mvn install:install-file -Dfile=path/to/sqljdbc41.jar -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc41 -Dversion=4.1 -Dpackaging=jar
And then declare the dependency as a standard dependency :
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc41</artifactId>
<version>4.1</version>
</dependency>
If you use a remote artifact repository (nexus, archiva...) you also need to deploy the artifact on this repository. You can find more here : https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html
Another way, you can put it into the resources folder, such as resources/lib/xxx.jar, then config the pom.xml like this:
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc41</artifactId>
<version>4.1</version>
<scope>system</scope>
<systemPath>${basedir}/src/main/resources/lib/sqljdbc41.jar</systemPath>
</dependency>
In Spring Boot: I also faced similar issue and below code helped me.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>1.5.7.RELEASE</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
</plugins>
</build>
It works for me:
project {root folder}/libs/ojdbc-11.2.0.3.jar
pom.xml:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>11.2.0.3</version>
<scope>system</scope>
<systemPath>${basedir}/libs/ojdbc-11.2.0.3.jar</systemPath>
</dependency>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
In my case, the fault was providing a version number without "dot" in tag:
<dependency>
<groupId>jdk.tools</groupId>
<artifactId>jdk.tools</artifactId>
<scope>system</scope>
<version>1</version>
<systemPath>${basedir}/src/main/resources/lib/tools.jar</systemPath>
</dependency>
This one works:
<dependency>
<groupId>jdk.tools</groupId>
<artifactId>jdk.tools</artifactId>
<scope>system</scope>
<version>1.8</version>
<systemPath>${basedir}/src/main/resources/lib/tools.jar</systemPath>
</dependency>
When Spring-Boot projects are used with maven or gradle plugins they packaged the applicaiton by default as executable jars.
These executable jars cannot be used as dependency in any another Spring-Boot project because the executable jar add classes in BOOT-INF/classes folder. This means that they cannot be found when the executable jar is used as a dependency because the dependency jar will also have the same class path structure as shown below.
If we want to use project-A as a maven dependency in project-B then we must have two artifacts. To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as a dependency.
To configure a classifier of exec in Maven, you can use the following configuration:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>exec</classifier>
</configuration>
</plugin>
</plugins>
</build>
So the MAJIC WORD here is <classifier>exec</classifier> this will create a jar structure as below and then it could easily be conusmed by spring-boot project as maven dependency jar on class path.
The above plugin need to be add in project-A pom that is going to be used as dependency in project-B. Same is explained in spring documentation section 16.5. as well.
In order to work through the local repository, the target .jar file that we will work with must be in the s2 folder. Several methods can be used for this:
The file can be taken manually and put in the relevant place (not
preferred). The same process can be done by installing it via the
console.
Relevant Remote URL is written in the .pom file dependencies and
automatically places it in the s2 folder when Intellij is refreshed
(validate) in the IDE used.
The same process can be done by addressing the .pom file dependencies via the centeral repository.
Attention: ComponentScan should not be forgotten for the related jar work on SpringBot.
I have 2 projects that I am using the FindBugs plugin in maven to identify bugs. I am also using the #SuppressFBWarnings annotation to ignore specific bugs.
With the first project, I added the dependancies to the pom.xml and both the findbugs report and the annotation worked fine. With the second project, the report gets generated, but it still identifies bugs that I have suppressed using the annotation.
I run mvn clean install site to generate the reports on my machine in the build folder.
Each of the 2 projects I mentioned, have sub-projects with their own pom.xml files in their sub-directories, so in the parent directory, I also have a pom.xml. This directory layout is mirrored identically in both of the main projects.
Here is the XML I added to the parent poms under the <reporting> tag:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<xmlOutput>true</xmlOutput>
<findbugsXmlOutput>true</findbugsXmlOutput>
<fork>true</fork>
<threshold>Low</threshold>
<effort>Min</effort>
</configuration>
</plugin>
Also, in this same parent pom, I added this to the <dependencyManagement><dependencies> section:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>2.0.1</version>
</dependency>
This is identical in both of the main projects poms.
Now, in the sub-projects where I actually use the #SuppressFBWarnings annotation, and only in that particular sub-project, I have this under <dependencies>:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>2.0.1</version>
</dependency>
Also, this is mirrored in the other working project. I copied and pasted directly.
One project works perfect and I can successfully suppress false positives. The other project completely ignores the #SuppressFBWarnings anotation, and I can't seem to fix it.
Is there something I'm missing here?
I think that if an annotation is not found, instead of giving an error, it will just ignore it? How can I tell if its not found?
Hopefully this is a simple fix.
Thanks.
#SuppressFBWarnings was introduced with the annotation in version 3. That's why it should look like this:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>3.0.1</version>
</dependency>
Try to add annotations artifcat to the plugin dependencies :
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<xmlOutput>true</xmlOutput>
<findbugsXmlOutput>true</findbugsXmlOutput>
<fork>true</fork>
<threshold>Low</threshold>
<effort>Min</effort>
</configuration>
<dependencies>
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>
</plugin>
Ensure that the dependency added is in between the dependencies tags.
Like this:
<dependencies>
<dependency>
<groupId>something</groupId>
<artifactId>something</artifactId>
<version>something</version>
</dependency>
<dependencies>