Develop Reference

Maven exclude/remove test dependency defined in parent POM

This is similar to Exclude dependency in child pom inherited from parent pom, except that it has to do with test vs compile scopes.
I have a parent POM that includes the org.slf4j:slf4j-api dependency so that all descendant projects will be using SLF4J for the logging API. Then, so that all projects can have some logging for unit tests (regardless of which SLF4J implementation they use in the main, that is non-test, part of the project), I include SLF4J Simple, but only in the test scope:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<scope>test</scope>
</dependency>
(I understand the view that parent POMs should not declare dependencies and only use dependency management. While I don't disagree in general, configuring tests is a different story. I don't want every single subproject to have to declare JUnit, Hamcrest, Hamcrest Optional, Mockito, Simple Logging, etc. The testing framework should be uniform across all our projects without a huge amount of ceremony just to set up a project.)
This works fine until one project Foo wants to use Logback as the SLF4J implementation.
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.4.1</version>
</dependency>
That works fine for the Foo application itself, but now for the Foo tests, there are suddenly two competing SLF4J implementations: Logback and SLF4J simple. This presents a bindings conflict:
SLF4J: Class path contains multiple SLF4J providers.
SLF4J: Found provider [ch.qos.logback.classic.spi.LogbackServiceProvider#363ee3a2]
SLF4J: Found provider [org.slf4j.simple.SimpleServiceProvider#4690b489]
SLF4J: See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual provider is of type [ch.qos.logback.classic.spi.LogbackServiceProvider#363ee3a2]
I need to do one of the following:
In the POM where I bring in the ch.qos.logback:logback-classic dependency, I need to exclude the org.slf4j:slf4j-simple from the parent POM. (This is the preferred solution.)
In the POM where I bring in the ch.qos.logback:logback-classic dependency, I need to specify that ch.qos.logback:logback-classic is for all scopes except the test scope (so as not to conflict with org.slf4j:slf4j-simple).
I don't readily see how to do either of these. Any ideas?
One suggestion was to redeclare org.slf4j:slf4j-simple with <scope>provided</scope>. Thus pom.xml for project Foo would look like this:
…
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<scope>provided</scope>
</dependency>
…
Unfortunately that doesn't work. SLF4J still sees two SLF4J providers on the classpath, and is showing the message seen above. A scope of provided simply keeps the dependency from being included transitively in other projects; it doesn't seem to remove it from the classpath of the current project.

It sounds like you are trying to build the Cathedral using wrong tools and instead of Cathedral you are getting pagan temple :)
technically, it is possible to override classpath/module dependencies imposed by parent pom by defining system scope, something like:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>2.0.1</version>
<scope>system</scope>
<systemPath>${project.basedir}/../dummy.jar</systemPath>
</dependency>
however, I wouldn't recommend to do that
another option is to take advantage of classpathDependencyExcludes config option of surefire plugin, something like:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<classpathDependencyExcludes>org.slf4j:slf4j-simple</classpathDependencyExcludes>
</configuration>
</plugin>
If particular parent does not suit child's needs, child may adopt another parent :) There is no strict requirement that the aggregator pom must be the parent pom
the real problem is unlike modern build tools maven does not distinguish test compile and test runtime scopes, however it is possible to emulate such behaviour
<properties>
<surefire.runtime>${project.build.directory}/surefire-runtime/slf4j-simple-2.0.1.jar</surefire.runtime>
</properties>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-surefire-runtime</id>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>2.0.1</version>
<type>jar</type>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/surefire-runtime/</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<additionalClasspathElements>${surefire.runtime}</additionalClasspathElements>
</configuration>
</plugin>
yep, too many words there, but in my opinion that is only correct configuration for test runtime dependencies, m.b. it worth to submit a corresponding PR to surefire project - I believe that needs to write about 10 LoC to avoid maven-dependency-plugin configuration and able to configure test runtime in the following way:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>org.slf4j:slf4j-api:2.0.1</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>

How to generate java stubs from protobuf for Java target 11 using maven?

I am trying to generate stub using protobuf.
My pom.xml has below code
<plugin>
<groupId>com.github.os72</groupId>
<artifactId>protoc-jar-maven-plugin</artifactId>
<version>3.8.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<protocVersion>3.8.0</protocVersion>
<includeStdTypes>true</includeStdTypes>
<inputDirectories>
<include>src/main/proto</include>
</inputDirectories>
<outputTargets>
<outputTarget>
<type>java</type>
</outputTarget>
<outputTarget>
<type>grpc-java</type>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.24.0</pluginArtifact>
</outputTarget>
</outputTargets>
</configuration>
</execution>
</executions>
</plugin>
However, it generates the source files with target as Java1.8.
I am migrating my apps to Java 11, and have included the below jars in pom.xml file:
<dependency>
<groupId>com.sun.activation</groupId>
<artifactId>javax.activation</artifactId>
<version>1.2.0</version>
</dependency>
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.activation-api</artifactId>
<version>1.3.2</version>
</dependency>
However maven protoc plugin generates the files Grpc.java with annotnation javax.annotation.Generated instead of javax.annotation.api.Generated
Is there any other way for generating the java stub with target version as JDK 11.

If you follow the grpc-java documentation, it instructs you to use:
<dependency> <!-- necessary for Java 9+ -->
<groupId>org.apache.tomcat</groupId>
<artifactId>annotations-api</artifactId>
<version>6.0.53</version>
<scope>provided</scope>
</dependency>
Previous versions of the examples used javax.annotation:javax.annotation-api:1.2, which does work, but it was replaced with Tomcat for licensing reasons. In your pom.xml, it seems you might have mixed up "activation" vs "annotation", which look pretty similar at a glance.
I'm not aware of a javax.annotation.api.Generated annotation. I've not seen any real evidence that javax.annotation.processing.Generated is an appropriate replacement for javax.annotation.Generated either.

Error while having multiple servlet-api libs on classpath

I have Spring Boot app running with embedded Tomcat. I'm running it in docker container. When I try to follow this page about spring boot in container and build layered image I recieve error mentioned below when I try to start the container. I know that the best way would be to exclude old version of servlet-api from my dependecies but it's impossible as this dependency stops working while I'm doing that. Unfortunately I cannot also get rid of this dependency. Is there a way to force Spring Boot to use specific implementation from classpath? I've tried Jetty and Undertow and docker successfully started but then lib that is using older version didn't work properly.
Other question is why it's working when I'm copy just jar and start it?
Dockerfile that I'm trying to build:
FROM adoptopenjdk:11-jre-hotspot
ARG DEPENDENCY=target/dep
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","com.test.App"]
Dockerfile that works:
FROM adoptopenjdk:11-jre-hotspot
COPY /target/application.jar /app/application.jar
COPY /target/lib /app/lib
ENTRYPOINT ["java", "-jar", "app/application.jar"]
The one that works requires additional plugins in pom.xml to make it possible:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>build-info</id>
<goals>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<finalName>ttom-osm-converter</finalName>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.tomtom.mep.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Dependecies from POM:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
<dependency> <!-- lib contains servlet-api-2.5 -->
<groupId>com.test.lib</groupId>
<artifactId>client</artifactId>
<version>${model.client.version}</version>
</dependency>
Error:
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [NonLoginAuthenticator[StandardEngine[Tomcat].StandardHost[localhost].TomcatEmbeddedContext[/path]
***************************
APPLICATION FAILED TO START
***************************
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.apache.catalina.authenticator.AuthenticatorBase.startInternal(AuthenticatorBase.java:1220)
The following method did not exist:
'java.lang.String javax.servlet.ServletContext.getVirtualServerName()'
The method's class, javax.servlet.ServletContext, is available from the following locations:
jar:file:/app/lib/servlet-api-2.5.jar!/javax/servlet/ServletContext.class
jar:file:/app/lib/javax.servlet-api-4.0.1.jar!/javax/servlet/ServletContext.class
jar:file:/app/lib/tomcat-embed-core-9.0.29.jar!/javax/servlet/ServletContext.class
It was loaded from the following location:
file:/app/lib/servlet-api-2.5.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of javax.servlet.ServletContext

From the error about 'java.lang.String javax.servlet.ServletContext.getVirtualServerName()', we can see that is was added in Servlet 3.1: you should exclude servlet-api:2.5.
Use the following command:
mvn dependency:tree -Dincludes='*:servlet-api'
This will list you all all module/dependencies including servlet-api.
Then excludes the bad version from dependencies: the com.test.lib client should not even includes it in the first place, meaning the dependency should be provided in it as well.
<dependency> <!-- lib contains servlet-api-2.5 -->
<groupId>com.test.lib</groupId>
<artifactId>client</artifactId>
<version>${model.client.version}</version>
<exclusions> <exclusion> <groupId>...</groupId> <artifactId>servlet-api</artifactId> </exclusion> </exclusions>
</dependency>
Do note that the servlet-api groupId changed over the course of time: that's probably one reason why Maven does not select the "good" servlet-api.
And I would advise you to use maven-enforcer-plugin to lock these bad dependencies:
<rules>
<bannedDependencies>
<excludes>
<exclude>*:servlet-api:2.5</exclude>
</excludes>
</bannedDependencies>
</rules>
<fail>true</fail>
See http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html for more information.
Now then you mention that your lib (com.test.lib) seems to not work without servlet-api 2.5, which means it use code that was probably removed between Servlet 2.5 and 3.1: your only course of action is to upgrade your lib as to not depends on said code:
The first servlet-api (2.5) is loaded
Tomcat and Spring Boot are compiled against later version
Tomcat/Spring Boot will may try to use a method added in later version
You will have another error and so on.

You can access to path:
~/.m2/repository/javax/servlet/servlet-api
And clear folder serverlet. For example:
rm -rf 2.5
Finally you re-run application and everything is ok.

NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.directExecutor conflits on Elastic Search jar

While creating Elasticsearch Client, I'm getting the exception java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.directExecutor()Ljava/util/concurrent/Executor;
After some lookup, seams like the Guava-18 is being overwrite by an older version at runtime, and Guava-18 only works during compile task.
My Maven configuration is the follow:
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.0</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
How can i force the Guava-18 version at execution time?

You should try to find where the "old" version of guava is taken from and to exclude it once for all.
Find the dependency :
mvn dependency:tree | grep guava
Exclude it :
<dependency>
<groupId>org.whatever</groupId>
<artifactId>the_lib_that_includes_guava</artifactId>
<version>0.97</version>
<exclusions>
<exclusion>
<artifactId>com.google</artifactId>
<groupId>guava</groupId>
</exclusion>
</exclusions>
</dependency>
See https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html for more info on the dependency exclusion.

I add the correct dependency of elasticsearch resolve the problem
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>18.0</version>
</dependency>

Add a dependencyManagement block solves this problem:
<dependencyManagement>
<!-- enforce dependency guava version 20.0 -->
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>20.0</version>
</dependency>
</dependencies>
</dependencyManagement>
Reference:
http://techidiocy.com/maven-dependency-version-conflict-problem-and-resolution/

I was also seeing the error message mentioned by the OP when creating an Elasticsearch Client instance. In my case it was occurring in a Spring Boot app at application startup. Spring Boot was attempting to auto-configure the Elasticsearch Client via dependencies brought in by spring-boot-starter-data-elasticsearch. The underlying guava version being brought in was:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>18.0</version>
</dependency>
This was all working fine until I introduced the following google-api-client dependency...
<dependency>
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client</artifactId>
<version>1.23.0</version>
</dependency>
...which depends on following guava dependency:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava-jdk5</artifactId>
<version>17.0</version>
</dependency>
This caused a class path collision and the fix was to exclude the older guava version from the google-api-client like so:
<dependency>
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client</artifactId>
<version>1.23.0</version>
<exclusions>
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava-jdk5</artifactId>
</exclusion>
</exclusions>
</dependency>

The best soltion is to use the shade plugin for maven. Adding this to your pom.xml should fix it:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<relocations>
<relocation>
<pattern>com.google.common</pattern>
<shadedPattern>shaded.com.google.common</shadedPattern>
</relocation>
</relocations>
<artifactSet>
<includes>
<include>com.google.guava:guava</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
This will create an upper jar with the same name including only a shaded guava inside.

I had a similar problem. I created a .jar file (Java source), then I wanted to load that file into the Spark Shell. It turns out that Spark Shell loads jars from something similar to this
spark-[version]-bin-hadoop[version]/jars/".
That directory had an older version of the guava which causes the error. I had the correct version in my pom.xml. I even added exclusions and all suggested responses. In conclusion, it is indeed a wrong version of guava. I copied the version that matches my pom.xml file. Hope this helps. Regards.

SOLVED: I updated the Guava dependency to latest version and it solved the
<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>latest</version>
</dependency>

I was struggling with this issue from past 2 months and finally found the solution.
I added too many external jars in my Project Structure which actually created some jars in Library Root resulting in conflicts whenever something is added in pom.xml.
So what needs to be done is delete all external jar files from your project and keep only the ones which are from maven like Maven:org...
My project structure:

For SBT solution:
Use shading the library in build.sbt
// Shading com.google.**
// We need com.google.guava above 18 version but spark uses version 14 and in that we don't have directExecutor() method
// as spark give preference to spark used libraries, our code was failing
assemblyShadeRules in assembly := Seq(
ShadeRule.rename("com.google.**" -> "shadeio.#1").inAll
)

Best way to consume RPC/encoded webservice?

I need to consume old-school RPC/encoded WSDL webservice for my backend. At first I tried to use Apache CXF and JAX-WS for that, but JAX-WS wsimport tool doesn't eat rpc/enoded WSDL.
[ERROR] rpc/encoded wsdls are not supported in JAXWS 2.0.
I'm also in doubt about using JAX-RPC for this job, because it's way out-dated. Axis 1.4 is 5 years old tool.
Currently I see these three options:
use JAX-WS javax.xml.ws.Dispatch to send and receive SOAP and parse it somehow, one example
use JAX-RPC and gain bad karma for using outdated technology,
do it all manually and hate myself later.
Neither of these sound too good, so I would appreciate if you could give some good leads, thought what to do and how to solve it.

UPDATE
My case was solved with hand editing WSDL from encoded to literal (basically under operations input and output use="literal" was the only replacement) and then I could generate stubs with Apache CXF. It could be done, because endpoint wasn't parsing RPC/encoded exactly and RPC/encoded spec XML couldn't be validated against WSDL).
Although Axis 1.4 may work for you, using Apache CXF with that little WSDL hack, may be a better way.
[Old answer]
For reference -- I opted for using JAX-RPC and Axis 1.4 this time. I generated client code and hopefully can replace it with JAX-WS implementation when service gets upgraded.

In case someone would like (well, "like" is not the right word here ;-) to use Axis 1.4, here is a maven plugin that can generate appropriate classes and Port interface.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>axistools-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>wsdl2java</goal>
</goals>
<configuration>
<!-- Use your .wsdl location here-->
<sourceDirectory>${basedir}/src/main/resources/wsdl</sourceDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<!-- Here the libraries that you need to call the Axis WS client -->
<dependencies>
<dependency>
<groupId>org.apache.axis</groupId>
<artifactId>axis</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>org.apache.axis</groupId>
<artifactId>axis-jaxrpc</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>commons-discovery</groupId>
<artifactId>commons-discovery</artifactId>
<version>0.5</version>
</dependency>
<dependency>
<groupId>axis</groupId>
<artifactId>axis-wsdl4j</artifactId>
<version>1.5.1</version>
</dependency>
<dependency>
<groupId>org.apache.axis</groupId>
<artifactId>axis-saaj</artifactId>
<version>1.4</version>
</dependency>
<!-- activation+mail: To stop Axis generating WARNING about "Attachment support being disabled" -->
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4.7</version>
</dependency>
</dependencies>

I have the same problem with a WS RPC style, I have a springboot project with eclipse and java 1.8 and this... WS from a provider(It means that I can't change the published wsdl).
If you're using springboot I 'm using the org.codehaus.mojo plugin to generate the sources and works.
store your wsdl in local (I put it in the root of my spring project Myspringproyectfolder/wsdl/servicio.wsdl)
In the WSDL change all the text from use="encoded" to use="literal" as the upper response says
Change in the POM plugin attributes the to the local WSDL modified instead of the original WSDL URL.
pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>wsimport-from-jdk</id>
<goals>
<goal>wsimport</goal>
</goals>
</execution>
</executions>
<configuration>
<wsdlUrls>
<wsdlUrl>wsdl/servicio.wsdl</wsdlUrl>
</wsdlUrls>
<keep>true</keep>
<packageName>com.cbb.facturalo.wsclient.generated</packageName>
<sourceDestDir>src/main/java</sourceDestDir>
</configuration>
</plugin>
4.- run the maven/install to generate the sources, port type, object factory, etcetc.