Related
Getting below warning while build.
I am using in pom.xml
<systemPath>${project.basedir}/lib/....jar</systemPath>
[WARNING] 'dependencies.dependency.systemPath' for ...:jar should not
point at files within the project directory,
${project.basedir}/lib/....jar will be unresolvable by dependent
projects # line 25, column 30
Its resolved now by using <systemPath>${pom.basedir}/lib/....jar in pom.xml
Anyone please explain, What is difference between ${pom.basedir} vs ${project.basedir} in pom.xml?
${basedir}, ${project.basedir} and ${pom.basedir} are synonyms (you may also check that using something like mvn help:evaluate -Dexpression=pom.basedir), your Q just reveals that person who was fixing MNG-4953 didn't know about that.
The problem: My software uses a library that every developer (and user) has installed in a different location.
The following works in pom.xml:
<project ...>
...
<dependencies>
<dependency>
<groupId>myGroup</groupId>
<artifactId>myName</artifactId>
<version>1.2.3</version>
<scope>system</scope>
<systemPath>C:\...\....jar</systemPath>
</dependency>
</dependencies>
</project>
But when I check this into source control, every developer who needs to change it, has to change the pom.xml, thus having to ignore it at every commit afterwards or to commit partially if he has to change anything else in the pom.xml, such as adding another dependency.
Using a property does not help, it just moves the problem to another location inside the pom.xml.
Using a property and reading it from an external file (properties-maven-plugin) seems not to work since the plugin is called after the dependency checks of e.g. Eclipse: Dynamically adding a Maven dependency from a property
Using environment variables ${env.MY_VARIABLE} seems not to work either: [ERROR] 'dependencies.dependency.systemPath' for myGroup:myName:jar must specify an absolute path but is ${env.MY_VARIABLE} #line 123, column 45
Any ideas on how to solve that?
I would use a repoistory for my jars. Something like nexus or artifactory.
https://www.sonatype.com/nexus-repository-sonatype
https://www.jfrog.com/open-source/
https://binary-repositories-comparison.github.io/
this option works for me:
3. Using environment variables ${env.MY_VARIABLE} seems not to work either: [ERROR] 'dependencies.dependency.systemPath' for myGroup:myName:jar must specify an absolute path but is ${env.MY_VARIABLE} #line 123, column 45
you have to put the jar name included in the path, for example, ${env.MY_VARIABLE/my_jar.jar}.
Also make sure that MY_VARIABLE exists in your environment.
at the end execute the mvn clean and mvn compile commands
I recompiled my classes as usual, and suddenly got the following error message. Why? How can I fix it?
java.lang.SecurityException: class "Chinese_English_Dictionary"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
This happens when classes belonging to the same package are loaded from different JAR files, and those JAR files have signatures signed with different certificates - or, perhaps more often, at least one is signed and one or more others are not (which includes classes loaded from directories since those AFAIK cannot be signed).
So either make sure all JARs (or at least those which contain classes from the same packages) are signed using the same certificate, or remove the signatures from the manifest of JAR files with overlapping packages.
A simple way around it is just try changing the order of your imported jar files which can be done from (Eclipse). Right click on your package -> Build Path -> Configure build path -> References and Libraries -> Order and Export. Try changing the order of jars which contain signature files.
A. If you use Maven, a useful way to debug clashing jars is:
mvn dependency:tree
For example, for an exception:
java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classes in the same package
we do:
mvn dependency:tree|grep servlet
Its output:
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- javax.servlet:jstl:jar:1.2:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile
shows clashing servlet-api 2.5 and javax.servlet 3.0.0.x.
B. Other useful hints (how to debug the security exception and how to exclude Maven deps) are at the question Signer information does not match.
In my case, I had duplicated JAR version of BouncyCastle in my library path :S
I had a similar exception:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package
The root problem was that I included the Hamcrest library twice. Once using Maven pom file. And I also added the JUnit 4 library (which also contains a Hamcrest library) to the project's build path. I simply had to remove JUnit from the build path and everything was fine.
This can occur with the cglib-instrumented proxies because CGLIB uses his own signer information instead of the signer information of the application target class.
After sign, access: dist\lib
Find extra .jar
Using Winrar, You extract for a folder (extract to "folder name") option
Access: META-INF/MANIFEST.MF
Delete each signature like that:
Name: net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.c
lass
SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
Save the file
Zip again
Renaime ext to .jar back
Already
I am having this problem with Eclipse and JUnit 5.
My solution is inspired by the previous answer by user2066936
It is to reconfig the ordering of the import libraries:
Right click the project.
Open [Java Build Path].
Click Order and Export.
Then push JUNIT to upper priority.
If you're running it in Eclipse, check the jars of any projects added to the build path; or do control-shift-T and scan for multiple jars matching the same namespace. Then remove redundant or outdated jars from the project's build path.
A bit of an old thread but since I was stuck for quite some time on this, here's the fix (hope it helps someone).
My scenario:
The package name is: com.abc.def. There are 2 jar files which contain classes from this package, say jar1 and jar2 i.e. some classes are present in jar1 and others in jar2. These jar files are signed using the same keystore but at different times in the build (i.e. separately). That seems to result in different signatures for the files in jar1 and jar2.
I put all the files in jar1 and built (and signed) them all together. The problem goes away.
PS: The package names and jar file names are only examples
In my case it was a package name conflict. Current project and signed referenced library had one package in common package.foo.utils. Just changed the current project error-prone package name to something else.
If you added all the jars from bouncycastle.org (in my case from crypto-159.zip), just remove the ones for the JDKs that do not apply to you. There are redundancies. You probably only need the "jdk15on" jars.
This question has lasted for a long time but I want to pitch in something. I have been working on a Spring project challenge and I discovered that in Eclipse IDE. If you are using Maven or Gradle for Spring Boot Rest APIs, you have to remove the Junit 4 or 5 in the build path and include Junit in your pom.xml or Gradle build file. I guess that applies to yml configuration file too.
This also happens if you include one file with different names or from different locations twice, especially if these are two different versions of the same file.
I could fix it.
Root Cause:
This is a common issue when using the Sun JAXB implementation with signed jars.
Essentially the JAXB implementation is trying to avoid reflection by generating a class to directly access the properties without using reflection. Unfortunately, it generates this new class in the same package as the class being accessed which is where this error comes from.
Resolution:
Add the following system property to disable the JAXB optimizations that are not compatible with signed jars:
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
Ref: https://access.redhat.com/site/solutions/42149
Based on #Mohit Phougat response, if you are running a Groovy with #Grab annotations, you could try to re-order such annotations.
I was getting a similar error when trying to use Mockito:
"$$FastClassByMockitoWithCGLIB$$abb8f5a0"'s signer information does not match signer information of other classes in the same package"
I was using an old version of Mockito, and upgrading to the latest Mockito version solved this problem. The issue was with CGLIB as mentioned in one of the other answers. In newer versions, Mockito replaces CGLIB with ByteBuddy, and so the problem goes away. I also had to add the new ByteBuddy jars to the classpath in Eclipse to get Mockito working again.
I was running JUNIT 5 and was also referencing Hamcrest external jar, but Hamcrest is also a part of the JUNIT 5 library. So, I moved the order of the external Hamcrest jar file to be above the JUNIT 5 library in the build path.
This happened to me when using JUnit + REST Assured + Hamcrest. In this case, don't add JUnit to your build path. If you have a Maven project, the below pom.xml file resolved this for me:
<dependencies>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
</dependency>
<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>
</dependencies>
I'm receiving the following error on log file.
(java.lang.SecurityException: class
"com.adventnet.snmp.snmp2.SecurityModelTable"'s signer information
does not match signer information of other classes in the same
package thrown
The thing is when I run the below command, it says the jar is verified.
/usr/jdk/instances/jdk1.5.0/bin/jarsigner -verify -verbose Jarfile.jar
If the jar file is verified then how can this problem occur?
It means that you have two or more classes in the same package with different signature data. Usually that means the classes come from different JARs, one of which is signed and the other is unsigned.
Check the pom dependency tree for same packages of different versions.
I had this issue with itext-2.1.7 including old bouncycastle's bcpkix that was included in a later version elsewhere.
Use this pattern:
<dependency>
package X
<exclusions>
<exclusion>
old package Y
</exclusion>
</exclusions>
</dependency>
<dependency>
latest package Y
</dependency>
Update: To check the dependency tree details of package_Y you can use mvn dependency:tree -Dverbose -Dincludes=package_Y. For more info check maven documentation on resolving dependency tree problems. Also Eclipse has quite a nice dependency tree viewer.
I encountered this exception while running a Scala/Spark project in Eclipse (Mars) on Windows and it prevented me from debugging and running the project in the IDE. The project used a Maven pom.xml file. It took a while to resolve, so I'm posting detailed steps here to help others:
Go to the folder where your project pom.xml file is
Run the command: mvn dependency:tree -Dverbose >Depends.Txt
Make sure you don't have a Depends.Txt or it will be overwritten!
Search in the Depends.Txt file for the unsigned class that the Eclipse IDE is complaining about. In my case, it was javax.servlet.
You may find it in a section that looks like this:
+- org.apache.hadoop:hadoop-mapreduce-client-core:jar:2.6.0:provided
+- javax.servlet:servlet-api:jar:2.5:provided
The Maven group ID that you want to exclude the duplicate class from in the above is: hadoop-mapreduce-client-core
Add an exclusions section listing the groupid of the exclusion in the pom.xml after the offending package. In my case, this was the groupid javax.servlet.
Note that you can't resolve this issue by reordering the Java build path as some have posted for a similar problem.
I encountered this issue in a Spring boot application. My issue was that I had JUnit on the build path which has Org.hamcrest.Matchers.* and Hamcrest which was resident in the library of the Spring framework in my pom.xml for the Eclipse repository. What I did was remove JUnit from my build path and included it only in my pom.xml. My application depended on Maven for JUnit and the *Matchers, so somehow you have two jars for one need, maybe as a library and as a configuration file.
In my program, I have loaded two versions of the same package. One is boprov-jdk15-140.jar, the other is bcprov-jdk15-151.jar. The two are conflicted.
In the JAR package's MANIFEST.MF file, it has the following digest:
Name: org/bouncycastle/crypto/digests/SM3Digest.class
SHA1-Digest: xxxxxxxx
The two JAR files have different SHA1-Digest info.
In my case I had:
Caused by: java.lang.SecurityException: class "org.bouncycastle.util.Strings"'s signer information does not match signer information of other classes in the same package
It was a project with a lot of dependencies and the mvn dependency:tree information did not really helped me.
Here is how I solved my issue:
I did a search "Find in files" using notepad++ on all the M2_REPO
I found a project which redefined "Strings" class in a package exactly identical to "org.bouncycastle.util.Strings" which should originate from the "org.bouncycastle:bcprov-jdk15on" dependency.
Once found, I moved all of these problematic classes in a new package and updated this project version.
Finally I updated the pom of the project which caused me trouble in the first place to use my dependency that uses the new package name.
Problem solved.
I had the following error:
java.lang.SecurityException: class “org.bouncycastle.asn1.ASN1ObjectIdentifier”‘s signer information does not match signer information of other classes in the same package
I was facing this exception when I was trying to make a PDF password protected.
I added the below jars to resolve the problem.
◾itextpdf-5.2.1.jar
◾bcmail-jdk16-1.46.jar
◾bcprov-jdk16-1.46.jar
◾bctsp-jdk16-1.46.jar
I recompiled my classes as usual, and suddenly got the following error message. Why? How can I fix it?
java.lang.SecurityException: class "Chinese_English_Dictionary"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
This happens when classes belonging to the same package are loaded from different JAR files, and those JAR files have signatures signed with different certificates - or, perhaps more often, at least one is signed and one or more others are not (which includes classes loaded from directories since those AFAIK cannot be signed).
So either make sure all JARs (or at least those which contain classes from the same packages) are signed using the same certificate, or remove the signatures from the manifest of JAR files with overlapping packages.
A simple way around it is just try changing the order of your imported jar files which can be done from (Eclipse). Right click on your package -> Build Path -> Configure build path -> References and Libraries -> Order and Export. Try changing the order of jars which contain signature files.
A. If you use Maven, a useful way to debug clashing jars is:
mvn dependency:tree
For example, for an exception:
java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classes in the same package
we do:
mvn dependency:tree|grep servlet
Its output:
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- javax.servlet:jstl:jar:1.2:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile
shows clashing servlet-api 2.5 and javax.servlet 3.0.0.x.
B. Other useful hints (how to debug the security exception and how to exclude Maven deps) are at the question Signer information does not match.
In my case, I had duplicated JAR version of BouncyCastle in my library path :S
I had a similar exception:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package
The root problem was that I included the Hamcrest library twice. Once using Maven pom file. And I also added the JUnit 4 library (which also contains a Hamcrest library) to the project's build path. I simply had to remove JUnit from the build path and everything was fine.
This can occur with the cglib-instrumented proxies because CGLIB uses his own signer information instead of the signer information of the application target class.
After sign, access: dist\lib
Find extra .jar
Using Winrar, You extract for a folder (extract to "folder name") option
Access: META-INF/MANIFEST.MF
Delete each signature like that:
Name: net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.c
lass
SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
Save the file
Zip again
Renaime ext to .jar back
Already
I am having this problem with Eclipse and JUnit 5.
My solution is inspired by the previous answer by user2066936
It is to reconfig the ordering of the import libraries:
Right click the project.
Open [Java Build Path].
Click Order and Export.
Then push JUNIT to upper priority.
If you're running it in Eclipse, check the jars of any projects added to the build path; or do control-shift-T and scan for multiple jars matching the same namespace. Then remove redundant or outdated jars from the project's build path.
A bit of an old thread but since I was stuck for quite some time on this, here's the fix (hope it helps someone).
My scenario:
The package name is: com.abc.def. There are 2 jar files which contain classes from this package, say jar1 and jar2 i.e. some classes are present in jar1 and others in jar2. These jar files are signed using the same keystore but at different times in the build (i.e. separately). That seems to result in different signatures for the files in jar1 and jar2.
I put all the files in jar1 and built (and signed) them all together. The problem goes away.
PS: The package names and jar file names are only examples
In my case it was a package name conflict. Current project and signed referenced library had one package in common package.foo.utils. Just changed the current project error-prone package name to something else.
If you added all the jars from bouncycastle.org (in my case from crypto-159.zip), just remove the ones for the JDKs that do not apply to you. There are redundancies. You probably only need the "jdk15on" jars.
This question has lasted for a long time but I want to pitch in something. I have been working on a Spring project challenge and I discovered that in Eclipse IDE. If you are using Maven or Gradle for Spring Boot Rest APIs, you have to remove the Junit 4 or 5 in the build path and include Junit in your pom.xml or Gradle build file. I guess that applies to yml configuration file too.
This also happens if you include one file with different names or from different locations twice, especially if these are two different versions of the same file.
I could fix it.
Root Cause:
This is a common issue when using the Sun JAXB implementation with signed jars.
Essentially the JAXB implementation is trying to avoid reflection by generating a class to directly access the properties without using reflection. Unfortunately, it generates this new class in the same package as the class being accessed which is where this error comes from.
Resolution:
Add the following system property to disable the JAXB optimizations that are not compatible with signed jars:
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
Ref: https://access.redhat.com/site/solutions/42149
Based on #Mohit Phougat response, if you are running a Groovy with #Grab annotations, you could try to re-order such annotations.
I was getting a similar error when trying to use Mockito:
"$$FastClassByMockitoWithCGLIB$$abb8f5a0"'s signer information does not match signer information of other classes in the same package"
I was using an old version of Mockito, and upgrading to the latest Mockito version solved this problem. The issue was with CGLIB as mentioned in one of the other answers. In newer versions, Mockito replaces CGLIB with ByteBuddy, and so the problem goes away. I also had to add the new ByteBuddy jars to the classpath in Eclipse to get Mockito working again.
I was running JUNIT 5 and was also referencing Hamcrest external jar, but Hamcrest is also a part of the JUNIT 5 library. So, I moved the order of the external Hamcrest jar file to be above the JUNIT 5 library in the build path.
This happened to me when using JUnit + REST Assured + Hamcrest. In this case, don't add JUnit to your build path. If you have a Maven project, the below pom.xml file resolved this for me:
<dependencies>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
</dependency>
<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>
</dependencies>