We Keep Coding

Hamcrest Matcher signer information does not match signer information of other classes in the same package

I'm trying to write some integration tests in my Spring Boot application using REST-Assured and JUnit5 but when I run the following:
#SpringBootTest(classes = ProductsApplication.class)
class ProductsApiTest {
#Before
public void setup() {
RestAssured.baseURI = "http://localhost:8080/test/api/products";
}
#Test
public void test1() {
ValidatableResponse statusCode = given().when().get().then().statusCode(200);
}
}
A nasty error comes up:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer
information does not match signer information of other classes in the
same package
Please take a look at 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>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.4.RELEASE</version>
<relativePath /> <!-- lookup parent from repository -->
</parent>
...
<dependencies>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-runner</artifactId>
<scope>test</scope>
</dependency>
...
<!-- https://mvnrepository.com/artifact/io.rest-assured/rest-assured -->
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
</dependency>
</dependencies>
<build>
...
</build>
</project>
Here are the Order and Export + the Libraries the Eclipse project uses:
How do I set up the Eclipse environment to work with REST-Assured and Hamcrest? Why would this exception be thrown?

I deleted the org.hamcrest.core_1.3.0.v201303031735.jar from my .p2 plugins folder and it worked for me.
I searched for "hamcrest" in "C:\Users\Dell.p2\pool\plugins" folder and found "org.hamcrest.core_1.3.0.v201303031735.jar" there.
I deleted it for this path.
Tried to run the test cases and it got passed with no failure in statusCode() method line.
Please suggest if anyone has a better solution.

In my case, the problem was solved by adding an explicit dependency to Hamcrest at the top of the dependency list in my pom.xml:
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest</artifactId>
<scope>test</scope>
</dependency>

This issue can also occur within Eclipse plugin development if you define your own dependency on a later version of hamcrest.
I worked around this by removing the hamcrest plugin from the platform definition:
Select Windows -> Preferences -> Plugin Development -> Running Platform -> Edit -> Content
Filter for "hamcrest"
Untick org.hamcrest.core

If you get this error in eclipse the problem is that eclipse already has a hamcrest-core library in its plugins folder which has priority over your maven hamcrest library.
What you can do is overwrite the eclipse one (careful to have the same version with the one you have in your maven repositories folder). I am using hamcrest-core 1.3.
I'll show the steps for MacOS but should be similar on Windows you just need to find the eclipse plugins folder and maven repositories folder on your own machine.
Close Eclipse.
Go to Eclipse plugins folder (on MacOS: ~/.p2/pool/plugins)
Find your hamcrest-core library (for me: org.hamcrest.core_1.3.0.v20180420-1519.jar)
Make a backup so that you can revert it - rename the file with a different extension (ex: org.hamcrest.core_1.3.0.v20180420-1519.bck)
Copy from the maven repositories (on MacOS: ~/.m2/repository) the hamcrest-core library into the plugins folder with the same name (on MacOS: cp ~/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar org.hamcrest.core_1.3.0.v20180420-1519.jar)
Open Eclipse and run the test, the test should now run correctly.

In my case I just removed the Eclipse's JUnit5 library from classpath.

Basic maven question: Does maven transitively install dependencies?

I've looked here https://blog.packagecloud.io/eng/2017/03/09/how-does-a-maven-repository-work/ and that does seem to be the case.
However, I tried to experiment with mvn install and I'm not sure if it's worked as expected. Here's what I did
(1) I created a lib.
(2) Ran mvn install from the command line
(3) Copied the path of my newly created jar
(4) Opened a new maven project, stuck the path into my pom.xml
I'm able to reuse my library methods, BUT: one of my library methods returns a TransportClient which is part of the elasticsearch api. Using intellij inside my new project, it seems like I don't have elasticsearch even though I'm referencing the jar.
Is this expected? I was expecting it to have transitively installed elasticsearch when it referenced my jar.
I'd love a pointer or two in the right direction, I'm completely new to this. :)
My pom.xml for the lib that uses elasticsearch as dependency.
<?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>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<groupId>estutorial</groupId>
<artifactId>estutorial</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.2</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.elasticsearch.client</groupId>
<artifactId>elasticsearch-rest-high-level-client</artifactId>
<version>6.4.2</version>
</dependency>
<dependency>
<groupId>org.elasticsearch.client</groupId>
<artifactId>transport</artifactId>
<version>6.4.2</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.11.1</version>
</dependency>
</dependencies>
</project>
My pom.xml for the new maven project that tries to reference the lib for the above 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>
<properties>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.source>1.8</maven.compiler.source>
</properties>
<groupId>sth</groupId>
<artifactId>sth</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.4</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>estutorial</groupId>
<artifactId>estutorial</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>/home/dell/.m2/repository/estutorial/estutorial/1.0-SNAPSHOT/estutorial-1.0-SNAPSHOT.jar
</systemPath>
</dependency>
</dependencies>
</project>

So, if I understand your steps, your dependency declaration in your referencing application uses a direct classpath to the jar file in your local repository? If so, this is unusual. You shouldn't need to know direct file locations for any of your dependencies of a Maven project. What you should be doing.
In the referenced project (that which requires the Elasticsearch library), it's pom.xml file would defined the elasticsearch dependency itself. This should follow maven standards for dependency declaration (groupId, artifactId and artifactVerion). If you don't have the elasticsearch artifact, maven will attempt to find it and store it in your local repository. You shouldn't have to have any path in your pom.xml file.
When you install the referenced project, it will install into your local repostory both the JAR file and the pom.xml.
In the referencing project, you should define the dependency to your referenced artifact in it's pom file. Same format: groupId, artifactId and artifactVersion. You shouldn't need to provide a specific path. What maven will do is find your referenced jar, but also use the installed POM.xml file for the referenced jar to find the transitive dependencies and include them in your classpath.
From what you've described, your dependency declarations aren't correct. If you can provide your POM file more details can be provided. Otherwise, review the maven intro to dependencies.

No. mvn install is a nearly useless command. It stuffs a jar file into your local repository, for subsequent use by other maven builds. You use the term 'path'. If you run mvn install:install-file to put a jar into your local repo under some coordinates, you can reference those coordinates from another pom; but it will generally lead to future problems as compare to deploying the jar into a proper repository manager.

Optional system dependency causes "invalid, transitive dependencies (if any) will not be available"

I have a main project and a commons project which has a dependency that is not in any repository and needs to be included using <scope>system</scope>.
Because the system dependency is defined using a relative url using a maven property ${project.basedir}, I made it <optional>true</optional> so that it doesn't bother other projects and so depending projects need to redefine this dependency with the correct path.
Commons pom.xml:
<dependency>
<groupId>thirdparty-group</groupId>
<artifactId>artifact</artifactId>
<version>1.4.2</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/dependency.jar</systemPath>
<optional>true</optional>
</dependency>
In main project's pom:
<dependency>
<groupId>my-group</groupId>
<artifactId>commons</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>thirdparty-group</groupId>
<artifactId>artifact</artifactId>
<version>1.4.2</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/dependency.jar</systemPath>
</dependency>
Obviously dependency.jar is in both the commons and main project.
The commons jar installs properly without a hitch. But when used in the main project however, the result is:
[WARNING] The POM for my-group:commons:jar:1.0-SNAPSHOT is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for my-group:commons:1.0-SNAPSHOT
[ERROR] 'dependencies.dependency.systemPath' for thirdparty-group:artifact:jar must specify an absolute path but is ${project.basedir}/lib/dependency.jar #
The build continues, but transitive runtime dependencies are now excluded breaking the application.
Why is maven complaining about a dependency from commons that is not even relevant to the main project (as it is optional, why is it even included as transitive dependency)?
How to work around this problem?
Putting the system dependency in the repo is not an option unfortunately.

Going by #PascalThivent's excellent answer, I worked around the issue by defining a local repo inside the commons project, and then changing the scope to compile with <optional>true</optional>.
In commons pom.xml:
<dependencies>
<dependency>
<groupId>thirdparty-group</groupId>
<artifactId>artifact</artifactId>
<version>0.0.1</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
</dependencies>
<repositories>
<repository>
<id>local-repo</id>
<url>file://${basedir}/lib/local-repo</url>
</repository>
</repositories>
To install the library:
mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
-Dfile=./lib/dependency.jar \
-DgroupId=thirdparty-group \
-DartifactId=artifact \
-Dversion=0.0.1 \
-Dpackaging=jar \
-DlocalRepositoryPath=.\lib\local-repo
I can just commit this to the VCS directly so other developers don't have to do this every time on checkout.
In the main project's pom.xml nothing changes. It can still use its own system dependency, or go this approach as well. Both approaches work for the WAR file that comes out there...

What is the difference between the GeoIP2 MaxMind pom and my local one?

I'm following this guide:
https://github.com/maxmind/GeoIP2-java
It says:
We recommend installing this package with Maven. To do this, add the dependency to your pom.xml:
<dependency>
<groupId>com.maxmind.geoip2</groupId>
<artifactId>geoip2</artifactId>
<version>2.2.0</version>
</dependency>
There is also pom.xml file in the Git repository of GeoIP2 which is much longer - what is the difference between them?

Cited from the official homepage:
Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
Think of the pom.xml as the heart of Maven. In the file you can specify dependencies (most typically jar files), and other information, such as how the project should be built. Without digging to deep into this, one of Maven's strengths is that it manages the dependencies of projects.
To answer your concrete question, GeoIP2 manages its dependencies using Maven. This section of its pom.xml defines them:
<dependencies>
<dependency>
<groupId>com.maxmind.db</groupId>
<artifactId>maxmind-db</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.google.http-client</groupId>
<artifactId>google-http-client</artifactId>
<version>1.20.0</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.5.3</version>
</dependency>
</dependencies>
By using Maven in your own project, you will only need to add the one dependency to GeoIP2. Maven will then search for the dependency in a repository, typically the Maven Central Repository if Maven isn't configured to use another. It will also automatically download all other needed dependencies (transitive dependencies), in this case it would be the dependencies listed above, plus any other dependencies those in turn depend on, and so on.
So, a short recap: Without a dependency management tool like Maven, you would need to manually make sure you have all the correct dependencies on the classpath. Maven fixes this for you.

Maven - moved code to new artifact; transitive dependencies issue

Here is my situation:
I created a new artifact in a library called 'web-ng-framework', and moved code into it from an old artifact in the library, 'web'
I deleted the 'web' artifact
And here is the problem:
ProjectA uses an older version of the library, and so it has a compile dependency on 'web'
ProjectB depends on ProjectA
ProjectB uses the latest version of the library, so when ProjectB is built, it contains both the 'web' and 'web-ng-framework' libraries, causing a possible conflict
Does anyone know how I can solve this? Thanks!
EDIT:
Would doing 'relocation' of 'web' to 'web-ng-framework' maybe work better? In ProjectA, I could include a dependency on 'web' so that Maven would see that what it really needs is 'web-ng-framework'. Would that work?

When including ProjectA in ProjectB exclude web. Like this
<dependency>
<groupId>your.group</groupId>
<artifactId>projectA</artifactId>
<exclusions>
<exclusion>
<groupId>your.group</groupId>
<artifactId>web</artifactId>
</exclusion>
</exclusions>
</dependency>

A classic solution to this problem is the 'Version 99' hack.
To do this, use the following in your root pom:
<dependencyManagement>
<dependency>
<groupId>your.group</groupId>
<artifactId>web</artifactId>
<version>99.0-does-not-exist</version>
</dependency>
</dependencyManagement>
Then put an empty web-99.0-does-not-exist.pom and web-99.0-does-not-exist.jar in your repository.
This ensures that every project that inherits from this root pom will not get the old version of the web.jar anymore.

I suggest that you use optional dependencies
This can be acheived by making web depencency optional in projectA.
<project>
<groupId>some.group</groupId>
<artifactId>projectA</artifactId>
...
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>some.group</groupId>
<artifactId>web</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
</dependencies>
</project>
When declaring some other project that depends on projectA the web dependency will not be included.
<project>
<groupId>some.group</groupId>
<artifactId>projectB</artifactId>
...
<dependencies>
<dependency>
<groupId>some.group</groupId>
<artifactId>projectA</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>some.group</groupId>
<artifactId>web-ng-framework</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</project>
Now projectB will only have a dependency on projectA and web-ng-framework, not web.