An excerpt from my project's dependency tree:
myproject
+- qxwebdriver-java 0.0.3
+- operadriver 1.5
| +- guava 14.0
+- selenium-java 2.52.0
+- selenium-remote-driver 2.52.0
| +- guava
+- selenium-safari-driver 2.52.0
Guava is required two times, via operadriver and selenium-remote-driver. In the latter case, dependency is declared without version. The project itself requires qxwebdriver-java and nothing more.
In this configuration, Safari driver does not work:
java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
at org.openqa.selenium.safari.SafariDriverCommandExecutor.start(SafariDriverCommandExecutor.java:111)
This happens because the project's overall dependency on Guava resolves to 14.0 (via operadriver). However the required Stopwatch::createStarted() method has been introduced in Guava 19.0. Manually adding Guava 19.0 dependency to the project's POM fixes the issue.
But isn't this an issue of Selenium and/or Opera driver packaging? Do you think it should be reported upstream, or is my workaround the right way to do things like this in Maven?
This is a perfectly common situation in Java and Maven, and not a defect.
The correct solution is to add an exclusion in your pom. Something like this:
<dependency>
<groupId>com.opera</groupId>
<artifactId>operadriver</artifactId>
<version>1.5</version>
<exclusions>
<!-- outdated library conflicts with selenium-java -->
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>[2.33.0,)</version>
<scope>test</scope>
</dependency>
Note that in rare cases - for example if guava version 19 deprecated something from version 14, that operadriver 1.5 depends on - doing this could break, in this case, operadriver.
Related
I am trying to use okhttp3.mockwebserver with my Spring boot project and I find out that okhttp3:mockwebserver:jar:3.14.9 is included instead of 4.9.1.
I have created small 'mock' projects to reproduce the issue I have in my prod.
The project is here https://github.com/mkarasik/okhttp-test
It contains two folders:
lib
This is a simple library including mockwebserver as dependency
pom.xml dependency
<dependencies>
...
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>mockwebserver</artifactId>
<version>4.9.1</version>
<exclusions>
<exclusion>
<artifactId>junit</artifactId>
<groupId>junit</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
Maven dependencies tree
\- com.squareup.okhttp3:mockwebserver:jar:4.9.1:compile
+- com.squareup.okhttp3:okhttp:jar:3.14.9:compile
This is already wrong. Mockwebserver pom contains 4.9.1 okhttp artifact, however 3.14.9 is shown in tree
project
Simple Spring Boot app including lib project
<dependency>
<groupId>com.example</groupId>
<artifactId>lib</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>test</scope>
</dependency>
Maven dependencies tree
\- com.example:lib:jar:0.0.1-SNAPSHOT:test
\- com.squareup.okhttp3:mockwebserver:jar:3.14.9:test
\- com.squareup.okhttp3:okhttp:jar:3.14.9:test
\- com.squareup.okio:okio:jar:1.17.2:test
The same problem is here. okhttp3:mockwebserver:jar:3.14.9 is included instead of 4.9.1 as it is specified in my lib pom.xml.
Is there anything I am missing in my xml configuration?
Found it it it is described in Introducing dependencies in other projects causes Maven to downgrade okhttp3 version
<properties>
<okhttp3.version>4.9.1</okhttp3.version>
</properties>
Fixes the issue
OkHttp provides a Maven BOM you can use to ensure a consistent version
https://github.com/square/okhttp#releases
Also, we have a bill of materials (BOM) available to help you keep
OkHttp artifacts up to date and be sure about version compatibility.
This example is gradle, but you it is originally a feature from maven.
https://docs.gradle.org/6.2/userguide/platforms.html#sub:bom_import
dependencies {
// define a BOM and its version
implementation(platform("com.squareup.okhttp3:okhttp-bom:4.9.3"))
// define any required OkHttp artifacts without version
implementation("com.squareup.okhttp3:okhttp")
implementation("com.squareup.okhttp3:logging-interceptor")
}
I have the spring-ws-security dependency in a Spring Boot 2.1.7 project:
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
</dependency>
Internally, the spring-ws-security pom has this dependency:
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j-ws-security-dom</artifactId>
<version>${wss4j.version}</version>
<exclusions>
...
</exclusions>
</dependency>
The parent of spring-ws-security is spring-ws, whose pom has a property:
<wss4j.version>2.2.0</wss4j.version>
I am trying to override this property in my pom file:
<properties>
<wss4j.version>2.2.4</wss4j.version>
...
</properties>
But it keeps taking the original 2.2.0 version:
$ mvn dependency:tree | grep wss4j
[INFO] | +- org.apache.wss4j:wss4j-ws-security-dom:jar:2.2.0:compile
[INFO] | | \- org.apache.wss4j:wss4j-ws-security-common:jar:2.2.0:compile
It takes the 2.2.4 version only if I explicitly supply the dependencies:
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j-ws-security-dom</artifactId>
<version>2.2.4</version>
</dependency>
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j</artifactId>
<version>2.2.4</version>
<type>pom</type>
</dependency>
Isn't overriding the property enough? Am I doing something wrong?
Here there are two points to consider:
One if you want to override the version in the properties in pom.xml, then your pom should have a parent-child relationship
second is if you want to use a particular version then we need to
declare the required version in your pom.xml explicitly and may
exclude the dependency from the third party jar and do a mvn clean install
Here is more information on dependency management and properties in maven
As I know, if you leave it blank without define any version. it will get the newest version of its library. So, you are right if you want to override the newest version to old version or certain version, by put the specific version. Have you trying to "mvn clean install" for that project?
We have been using Android API version 17 in a project and wish to upgrade to API version 19 because the application runs on Android 4.4.
We use Maven as our build environment. I have replaced all the occurrences of SDK version 17 to 19 in our AndroidManifest.xml. But I am having problems upgrading to the 4.4 platform through Maven.
I used the Android SDK Deployer tool to push the android-4.4 package into my local Maven repository. I then replaced the reference to android-4.2 to android-4.4 in our 'parent' POM.xml:
<dependencyManagement>
<dependencies>
<dependency>
<!-- <groupId>com.google.android</groupId> OLD -->
<groupId>android</groupId>
<artifactId>android</artifactId>
<!-- <version>4.2.2_r2</version> OLD -->
<version>4.4.2_r4</version>
<scope>provided</scope>
</dependency>
This change seemed to introduce a conflict. Another dependency is bringing in version 2.1_r1 of android package which is conflicting with the new 4.4.2_r4 package:
Excerpt from 'mvn dependency:tree':
.
[INFO] +- com.github.tony19:logback-android-classic:jar:1.0.10-2:compile
[INFO] | \- com.github.tony19:apktool-lib:jar:1.4.4-3:compile
[INFO] | \- com.google.android:android:jar:2.1_r1:compile
[INFO] | +- org.khronos:opengl-api:jar:gl1.1-android-2.1_r1:compile
[INFO] | +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] | \- xpp3:xpp3:jar:1.1.4c:compile
I noticed that if I move the <dependency> declaration of the 4.4 package above the logback-android-classic dependency declaration in pom.xml then our module will use the 4.4 dependency. However I don't think this is a proper fix, and I am running into various issues building the project as a whole.
Can those more experienced with Maven please advise on the correct way to resolve this?
Going through each affected module and adding an exclusion to the logback-android-classic dependency seems to have resolved it:
<exclusions>
<exclusion>
<artifactId>android</artifactId>
<groupId>android</groupId>
</exclusion>
<exclusion>
<artifactId>android</artifactId>
<groupId>com.google.android</groupId>
</exclusion>
</exclusions>
My app is throwing NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch error. Not sure why, because 16.0.1 do contain that class, I've checked. From what I have researched, it looks like this is a bug?
I also have this code for refernence, though I think this is not the issue:
FirewallRule rule = new PeriodicFirewallCounterRule(60, TimeUnit.SECONDS, new IpAddressCountingPolicy());
((PeriodicFirewallCounterRule)rule).addHandler(new RateLimitationHandler(new UniqueLimitPolicy(10)));
FirewallFilter firewallFiler = new FirewallFilter(getContext(), list(rule));
firewallFiler.setNext(ma);
My app is using Restlet APISpark:
<dependency>
<groupId>org.restlet.gae</groupId>
<artifactId>org.restlet.ext.apispark</artifactId>
<version>${version.restlet}</version>
</dependency>
When running and accessing the REST api of the app, it throws this
error:
[INFO] Caused by: java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
[INFO] at org.restlet.ext.apispark.internal.firewall.rule.counter.PeriodicCounter.<init>(PeriodicCounter.java:65)
[INFO] at org.restlet.ext.apispark.internal.firewall.rule.PeriodicFirewallCounterRule$1.load(PeriodicFirewallCounterRule.java:86)
[INFO] at org.restlet.ext.apispark.internal.firewall.rule.PeriodicFirewallCounterRule$1.load(PeriodicFirewallCounterRule.java:84)
[INFO] at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
[INFO] at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
[INFO] at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
[INFO] at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
[INFO] ... 74 more
When using the extension org.restlet.ext.apispark, the guava dependency retrieved has the version 16.0.1.
Downloading: http://maven.restlet.com/com/google/guava/guava/16.0.1/guava-16.0.1.jar
Downloading: http://repo.maven.apache.org/maven2/com/google/guava/guava/16.0.1/guava-16.0.1.jar
Downloaded: http://repo.maven.apache.org/maven2/com/google/guava/guava/16.0.1/guava-16.0.1.jar (2176 KB at 711.7 KB/sec)
It comes within an application created from scratch with the following maven configuration:
<project (...)>
<modelVersion>4.0.0</modelVersion>
<groupId>org.restlet</groupId>
<artifactId>restlet-apispark-firewall</artifactId>
<name>${project.artifactId}</name>
<packaging>jar</packaging>
<version>1.0.0-snapshot</version>
<properties>
<java-version>1.7</java-version>
<restlet-version>2.3.1</restlet-version>
</properties>
<dependencies>
<dependency>
<groupId>org.restlet.jse</groupId>
<artifactId>org.restlet</artifactId>
<version>${restlet-version}</version>
</dependency>
<dependency>
<groupId>org.restlet.jse</groupId>
<artifactId>org.restlet.ext.apispark</artifactId>
<version>${restlet-version}</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>maven-restlet</id>
<name>Public online Restlet repository</name>
<url>http://maven.restlet.com</url>
</repository>
</repositories>
</project>
I integrated your code and it works fine on my side. No exception is thrown...
I think that an older version of Guava comes from another dependency. If you use Maven, you should identify where this old guava version comes from and perhaps add an exclude within the corresponding dependency. I hope that it will fix your problem...
Hope that helps you,
Thierry
This is the solution that fixed the error:
First exclude old Guava dependency then:
<dependency>
<groupId>org.restlet.gae</groupId>
<artifactId>org.restlet.ext.apispark</artifactId>
<version>${version.restlet}</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.5.1</version>
</dependency>
The class Stopwatch loaded by that ClassLoader does not contain that method, not sure if caused by multiple incompatible jars as Jens says or simply because 16.0.1 does not really have that method.
A simple check will be to parse the class with javap or a decompiler:
javap -p Stopwatch.class
And then check if that method is listed.
Edit: That method is there since 15.0, so i'd check the content of you classpath too.
Referring to NoSuchMethodError Oracle Documentation :
The NoSuchMethodError: is thrown if an application tries to call a specified method of a class (either static or instance), and that class no longer has a definition of that method.
Normally, this error is caught by the compiler; this error can only occur at run time if the definition of a class has incompatibly changed.
I think you got this Exception because you have more than one version of this jar in your classpath, and since the createStarted() method is available from the 15.0 version I whould say that you have an other old version of it, probably due to a dependency problem.
Moving to the latest version of Guava did it for me
In my case one of my Maven dependencies was picking up a newer version of Guava (16.0.1) that apparently does not have this method. When I added an exclusion to that dependency in my pom.xml, instead an older (correct) version of Guava was picked up by another of my dependencies and then it worked.
You can find this by printing your dependency tree via mvn dependency:tree and then looking at what is picking up the newer version of guava. You might need to add more than one exclusion to get it right.
I'm trying to mock a constructor using PowerMockito but every time I run the test I get the following error:
java.lang.NoSuchMethodError: org.mockito.internal.creation.MockSettingsImpl.setMockName(Lorg/mockito/mock/MockName;)Lorg/mockito/internal/creation/settings/CreationSettings;
at org.powermock.api.mockito.internal.mockcreation.MockCreator.createMethodInvocationControl(MockCreator.java:107)
at org.powermock.api.mockito.internal.mockcreation.MockCreator.mock(MockCreator.java:60)
at org.powermock.api.mockito.internal.expectation.DefaultConstructorExpectationSetup.createNewSubstituteMock(DefaultConstructorExpectationSetup.java:105)
at org.powermock.api.mockito.internal.expectation.DefaultConstructorExpectationSetup.withAnyArguments(DefaultConstructorExpectationSetup.java:71)
I have the following PowerMock dependencies in my project:
org.powermock:powermock-module-junit4:1.5.6
org.powermock:powermock-mockito-release-full:1.5.6
I've traced the dependency tree of my project and fixed conflicts so that mockito-all:1.9.5 gets included in the build.
Make sure powermockito and mockito versions are aligned as in this versions chart - MockitoUsage#supported-versions,
Mockito | PowerMock
------------------------------------------------------------------------------
2.0.0-beta - 2.0.42-beta | 1.6.5+
------------------------------------------------------------------------------
1.10.19 | 1.6.4
1.10.8 - 1.10.x | 1.6.2+
1.9.5-rc1 - 1.9.5 | 1.5.0 - 1.5.6
1.9.0-rc1 & 1.9.0 | 1.4.10 - 1.4.12
1.8.5 | 1.3.9 - 1.4.9
1.8.4 | 1.3.7 & 1.3.8
1.8.3 | 1.3.6
1.8.1 & 1.8.2 | 1.3.5
1.8 | 1.3
1.7 | 1.2.5
Easy way to find mockito and powermock-mockito version using maven is,
mvn dependency:tree | grep mockito
[INFO] | \- org.mockito:mockito-core:jar:1.8.5:compile
[INFO] +- org.mockito:mockito-all:jar:1.8.5:compile
[INFO] +- org.powermock:powermock-api-mockito:jar:1.4.9:compile
Problem could be the conflicting versions of mockito in the application and the one that powermockito uses, conflicting as below in my case where I'm using powermock 1.6.5 which does not support mockito 1.8.5
mvn clean dependency:tree | grep mockito
[INFO] +- org.mockito:mockito-all:jar:1.8.5:compile
[INFO] \- org.powermock:powermock-api-mockito:jar:1.6.5:compile
[INFO] +- org.mockito:mockito-core:jar:1.10.19:compile
[INFO] \- org.powermock:powermock-api-mockito-common:jar:1.6.5:compile
I had
org.mockito
mockito-all
1.8.4
added to my pom.xml apart from powermock's dependecies, removing this worked for me.
My problem was due to conflicting versions of javassist in my project's (transitive) dependencies. What I did was search for all dependencies that put old version of javassist in the build, then exclude them. For example:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.5.1-Final</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
</exclusion>
</exclusions>
</dependency>
while migrating springboot from 1.5 to 2.0.7
The versions of mockito in springboot and powermock are different so explicitly give mockito dependency
This is compatible while migrating to springboot 2.0.7
testCompile "org.powermock:powermock-api-mockito2:${powermockVersion}"
testCompile group: 'org.mockito', name: 'mockito-core', version: '2.8.9'
testCompile "org.powermock:powermock-module-junit4:1.7.3"
testCompile "org.powermock:powermock-core:1.7.3"
For me, in Eclipse, the fix to this problem was found in Java Build Path. Click on Order and Export tab. Move Web App Libraries to bottom. Note, that when appropriate, this will also allow you to view source of 3rd party libraries when Eclipse tells you that source cannot be found.
In my case it was a conflict dependency.
I had fix it after exclude mockito-core artifact:
<dependency>
<groupId>com.googlecode.catch-exception</groupId>
<artifactId>catch-exception</artifactId>
<exclusions>
<exclusion>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
</exclusion>
</exclusions>
<version>1.0.4</version>
<scope>test</scope>
</dependency>
Also, consider removing PowerMock, bytebuddy and objenesis dependencies at all. Keep only the following Mockito dependency.
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.7.12</version>
<scope>test</scope>
</dependency>
This should fix the error for the most part of the scenarios.