My project depends on the Pax Exam framework. I declare, among others, these dependencies on Pax (PAX_EXAM_VERSION = 3.4.0):
compile group: 'org.ops4j.pax.exam', name: 'pax-exam-junit4', version: PAX_EXAM_VERSION
compile group: 'org.ops4j.pax.exam', name: 'pax-exam-container-native', version: PAX_EXAM_VERSION
Both of these depend on org.ops4j.pax.exam:pax-exam-spi, which is the module causing my issue.
So, when I try to build my project, the error reported is this one:
Could not resolve org.ops4j.pax.exam:pax-exam-spi:3.4.0
...
Could not parse POM http://repo.maven.apache.org/maven2/org/ops4j/pax/exam/pax-exam-spi/3.4.0/pax-exam-spi-3.4.0.pom
Unable to resolve version for dependency 'com.google.guava:guava:jar'
I have tried:
excluding pax-exam-spi from the transitive dependencies of the modules I depend on (but notice I still need the classes in it to be able to compile), adding Guava to my first-level dependencies, then trying to make pax-exam-spi a first-level dependency with transitive = false (won't work, same problem as above).
same as above, but instead of doing transitive = false, trying to use artifact-only notation, like this:
compile "org.ops4j.pax.exam:pax-exam-spi:${PAX_EXAM_VERSION}#jar"
I know the root of the problem is that the guava version is not declared in the pax-exam-spi pom, but in its parent exam, which only declares the Guava version(s) to use in 2 different profiles' dependencyManagement sessions (this works in Maven because one of the profiles is activated if the property glassfish.release is NOT set, and the other if that property IS set). However, knowing this has not been useful so far :(
Please let me know if there's any not-so-hacky way to make sure Gradle does include the pax-exam-spi's jar in my classpath, but does not even try to parse its POM (in particular, referring to a hard-coded path to the jar is out of question!).
Related
My gradle project contains 3 sub-projects with one source file each:
root-project\
sub-project-abstract\
...AbstractFoo.java
sub-project-commons\
...ConcreteFoo.java (extends AbstractFoo)
sub-project-main\
...Main.java (instantiates ConcreteFoo)
build.gradle of sub-project-commons:
dependencies {
implementation(project(:sub-project-abstract))
}
build.gradle of sub-project-main:
dependencies {
implementation(project(:sub-project-commons))
}
The Main-class in sub-project-main is aware of ConcreteFoo, however, compilation fails with cannot access AbstractFoo.
For some reason, I expected sub-project-commons to "export" ConcreteFoo and AbstractFoo, since it's a implementation-dependency. Or in other words, form the perspective of sub-project-main, AbstractFoo is a transitive dependency.
However, this doesn't seem to be the case.
I know that I could probably make it work by explicitly adding sub-project-abstract as a direct dependency to sub-project-main. However, that's something I want to avoid due to the nature of the commons project (my actual project contains up to 10 subprojects, and it should be possible to reuse the commons-project without declaring a dependency to sub-project-abstract every single time the commons-project is referenced.
Is there a way to make the Main-class aware of AbstractFoo without directly declaring sub-project-abstract as a dependency (but indirectly via sub-project-commons)?
This is expected behavior for the implementation configuration. You should apply the Java Library Plugin and use the api configuration.
The key difference between the standard Java plugin and the Java Library plugin is that the latter introduces the concept of an API exposed to consumers. A library is a Java component meant to be consumed by other components. It’s a very common use case in multi-project builds [emphasis added], but also as soon as you have external dependencies.
The plugin exposes two configurations that can be used to declare dependencies: api and implementation. The api configuration should be used to declare dependencies which are exported by the library API, whereas the implementation configuration should be used to declare dependencies which are internal to the component.
[...]
Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers. Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. [...]
In sub-project-commons (Kotlin DSL):
plugins {
...
`java-library`
}
...
dependencies {
api(project(":sub-project-abstract"))
}
...
When running a project built by maven with the following dependencies:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
I get the following error at runtime:
java.lang.SecurityException: class "javax.persistence.Cacheable"'s signer information does not match signer information of other classes in the same package
The javax.persistence-2.2.0 artifact is signed and contains the javax.persistence.Cacheable.class annotation, while the eclipselink-2.7.0 artifact is not signed and also contains the same java class annotation.
How can this be fixed?
Edit
Replacing the javax.persistence artifact version 2.2.0 by the version 2.1.1 fixes the problem (this one is not signed), but I'm not sure it's a normal situation.
Thanks Stéphane - the edit at the end of your question helped me "fix" the same problem. For anyone else who hits this as well - here is an expanded answer. This is what you need to "fix" things in your pom (until Eclipse fix things properly):
<!-- See https://stackoverflow.com/q/45870753 -->
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.1.1</version>
</dependency>
This pulls in eclipselink but excludes the javax.persistence dependency that it tries to pull in and replaces it with an earlier version of javax.persistence that doesn't have the signing issue.
Aside: javax.persistence version 2.2.0 is explicitly pulled in, in the pom fragment shown in the original question, despite already being a transitive dependency of eclipselink.
Explanation
Summary - the eclipselink artifact depends on javax.persistence and both contain classes that are in the package javax.persistence. However the javax.persistence jar is signed while the eclipselink one is not. So the Java runtime will complain, when loading a class from the package javax.persistence in the eclipselink jar, that it's lack of signing doesn't match with classes already loaded from the same package in the javax.persistence jar.
Details - if I put a breakpoint in java.util.concurrent.ConcurrentHashMap.putIfAbsent(K, V) with condition "javax.persistence".equals(arg0) then I see that javax.persistence is mapped to the following CodeSource value:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/javax.persistence/2.2.0/javax.persistence-2.2.0.jar [
[
Version: V3
Subject: CN="Eclipse Foundation, Inc.", OU=IT, O="Eclipse Foundation, Inc.", L=Ottawa, ST=Ontario, C=CA
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
...
I.e. javax.persistence-2.2.0.jar is signed by the Eclipse Foundation and contains classes in the package javax.persistence. This jar is pulled in when some part of my application (actually something deep in Spring logic) tries to load javax.persistence.EntityManagerFactory.
If I then put a breakpoint in java.lang.ClassLoader.checkCerts(String, CodeSource) on the throw new SecurityException line I then see that it hits this line when the passed in CodeSource is:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar <no signer certificates>)
I.e. eclipselink-2.7.0.jar also contain classes that are in the javax.persistence package but it is unsigned so a clash occurs that results in a SecurityException being thrown. This happens when something (also deep in Spring logic) tries to load javax.persistence.PersistenceUtil.
If I look at the output of mvn dependency:tree I see that this mismatch seems to be down to eclipselink itself - it is pulling in org.eclipse.persistence:javax.persistence:jar:2.2.0 itself. I.e. it isn't some clash with some other dependency:
[INFO] | \- org.eclipse.persistence:eclipselink:jar:2.7.0:compile
[INFO] | +- org.eclipse.persistence:javax.persistence:jar:2.2.0:compile
[INFO] | +- org.eclipse.persistence:commonj.sdo:jar:2.1.1:compile
[INFO] | +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] | \- org.glassfish:javax.json:jar:1.0.4:compile
I've logged this now at bugs.eclipse.org - see bug 525457.
To fix this issue, put in the correct JPA 2.2 compliant dependency for EclipseLink 2.7.x, in your maven pom file, as:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa</artifactId>
<version>2.7.1</version>
</dependency>
eclipselink.jar as such is designed as all-in-one bundle, not osgi enabled jar containing all partsof eclipselink project (ie sdo, oracle db specific stuff, dbws, nosql..) with ability to run with jpa api 2.0 on the classpath - at least in 2.x versions. In many cases this is not needed and proper components can be used instead, such as org.eclipse.persistence.jpa, org.eclipse.persistence.oracle etc. For the full list see ie: http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.persistence
This strange situation still seems to exist, in my case not using Maven, just trying to get a simple JPA example to run (and it is really frustrating if you need hours just to achieve that).
With 2.7.4 from January, this error occurs if you put the eclipselink.jar and jakarta.persistence_2.2.2.jar from the zip on the classpath.
In the end solution was to change order on the classpath: first the jakarta-persistence and only after that the eclipselink-jar.
So all javax.persistence classes are taken from jakarta-jar and not partly of the eclipselink-jar (if included there).
So I really wonder various things.
The eclipselink package should be all-in-one? But it is not. Some javax.persistence classes are contained. Others not - basic classes to be used in JPA code like EntityManager. Of course, together with the jakarta-jar included in the zip it is complete - but you may not use the two jars together with the "wrong" order on the classpath!? I really consider this a bug - or at least there should be a HUGE hint about this in the package then.
What is the org.eclipse.persistence.jpa-2.7.4.jar from Maven that is suggested here? It does not have the problems of the eclipselink.jar yes, not this error message. But then it also just seems not to include the Eclipselink JPA implementation, at least running with it I got error that persistence-unit referenced in code does not exist (same persistence.xml working with eclipselink.jar).
Strange situation.
My project was working on JDK-8, but stopped to work when I upgraded it to openJDK-11.
I solved it excluding the jpa-persistence module, and adding again on the version 2.2:
dependencies.create('org.eclipse.persistence:eclipselink:2.7.4') {
exclude module: "javax.persistence"
},
'javax.persistence:javax.persistence-api:2.2', //add it again, manually
'org.eclipse.persistence:org.eclipse.persistence.asm:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.antlr:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.moxy:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.core:2.7.4'
I fixed this by switching the order in which the jars appear in the classpath. In my case, I'm using Tomcat and had to modify catalina.properties to put javax before eclipselink.
Obinna's answer is correct; I guess that there was an issue with eclipselink 2.7.x –as George indicated. I had a similar issue when upgrading eclipselink, but it was just wrong artefacts. The initially described issue seems to be a result of externally referencing javax.persistence level - it is definitely not necessary.
Proper maven configuration can be found in eclipselink wiki:
https://wiki.eclipse.org/EclipseLink/Maven
I also run into this problem, with my case being a bit different, in that I am not using Maven. However, I place an answer here, as it might give people an idea about how to deal with this in their own situation. After all, the title is about this mismatch, in general, one sub-case being when using Maven.
I am using eclipselink in a NetBeans project. Initially, I was placing both the the eclipselink jar file (eclipselink-2.7.0.jar) and the needed org.eclipse.persistence jar files as external libraries to my project. Comments by Sergey and entreprenr above are what actually lead me to solve my problem. What I had to do was create a new library (Tools->Libraries->New Library...) which does not contain the eclipselink jar file (i.e. eclipselink-2.7.0.jar is not added in the library), only the specific org.eclipse.persistence jar files that are necessary for the project, e.g. org.eclipse.persistence.antlr-2.7.0.jar, org.eclipse.persistence.asm-2.7.0.jar, org.eclipse.persistence.core-2.7.0.jar, org.eclipse.persistence.jpa.modelgen.processor-2.7.0.jar, org.eclipse.persistence.jpa-2.7.0.jar, etc. I then added this library to my project and the exception vanished.
Of course, I also had to replace all org.eclipse.persistence jar files on my server with their 2.7.0 version and also replace the javax.persistence.jar with its 2.2.0 version (I use payara, so these are located under <payara_home>\glassfish\modules).
I'm using gradle in my project build and to solve the OP's problem, which I had as well, I finally used the following working setup.
dependencies {
testImplementation(group: 'org.eclipse.persistence', name: 'eclipselink', version: '2.7.4') {
exclude group: 'javax.validation', module: 'validation-api'
exclude group: 'org.eclipse.persistence', module: 'javax.persistence'
exclude group: 'org.eclipse.persistence', module: 'commonj.sdo'
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
testImplementation(group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4') {
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
}
Instead of "testImplementation" you can of course use any dependency type you want or need.
After reading Sergey's comment I've improved this by just using:
dependencies {
testImplementation group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4'
}
I think the last one is the best solution.
Because I could not find an answer for this problem when only using a Tomcat and this thread is often linked with this problem, I am going to post my solution here:
Since the signature is in the MANIFEST.MF you can change the signatures in the .jar files using 7zip or WinRAR to open them or simply delete them from the META-INF files of both .jar's and then import the changed files to your IDE.
A useful thread for the Signature-Mismatch-Problem is this thread: Java SecurityException: signer information does not match
Project I am working on requires the use of both Elasticsearch and a dependency (I didn't design or get to dictate its design) that utilizes Lucene and running into a version conflict between the two. The following error is spit out when I try to start the project
Exception in thread "main" java.lang.NoSuchFieldError: LUCENE_5_2_1
at org.elasticsearch.Version.<clinit>(Version.java:39)
at org.elasticsearch.common.io.stream.StreamOutput.<init>(StreamOutput.java:74)
at org.elasticsearch.common.io.stream.BytesStreamOutput.<init>(BytesStreamOutput.java:60)
at org.elasticsearch.common.io.stream.BytesStreamOutput.<init>(BytesStreamOutput.java:57)
at org.elasticsearch.common.io.stream.BytesStreamOutput.<init>(BytesStreamOutput.java:47)
at org.elasticsearch.common.xcontent.XContentBuilder.builder(XContentBuilder.java:69)
at org.elasticsearch.common.settings.Setting.arrayToParsableString(Setting.java:726)
at org.elasticsearch.common.settings.Setting.lambda$listSetting$26(Setting.java:672)
at org.elasticsearch.common.settings.Setting$2.getRaw(Setting.java:676)
at org.elasticsearch.common.settings.Setting.lambda$listSetting$24(Setting.java:660)
at org.elasticsearch.common.settings.Setting.listSetting(Setting.java:665)
at org.elasticsearch.common.settings.Setting.listSetting(Setting.java:660)
at org.elasticsearch.common.network.NetworkService.<clinit>(NetworkService.java:50)
at org.elasticsearch.client.transport.TransportClient.newPluginService(TransportClient.java:91)
at org.elasticsearch.client.transport.TransportClient.buildTemplate(TransportClient.java:119)
at org.elasticsearch.client.transport.TransportClient.<init>(TransportClient.java:247)
at org.elasticsearch.transport.client.PreBuiltTransportClient.<init>(PreBuiltTransportClient.java:92)
at org.elasticsearch.transport.client.PreBuiltTransportClient.<init>(PreBuiltTransportClient.java:81)
at org.elasticsearch.transport.client.PreBuiltTransportClient.<init>(PreBuiltTransportClient.java:71)
Any idea on whether or not its possible to resolve without being able to dictate the design of the dependency or Elasticsearch?
Ended up adding the Lucene core dependency version that is being mentioned in the error to the project. build.gradle now contains compile group: 'org.apache.lucene', name: 'lucene-core', version: '5.2.1' and that solved the problem.
When running a project built by maven with the following dependencies:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
I get the following error at runtime:
java.lang.SecurityException: class "javax.persistence.Cacheable"'s signer information does not match signer information of other classes in the same package
The javax.persistence-2.2.0 artifact is signed and contains the javax.persistence.Cacheable.class annotation, while the eclipselink-2.7.0 artifact is not signed and also contains the same java class annotation.
How can this be fixed?
Edit
Replacing the javax.persistence artifact version 2.2.0 by the version 2.1.1 fixes the problem (this one is not signed), but I'm not sure it's a normal situation.
Thanks Stéphane - the edit at the end of your question helped me "fix" the same problem. For anyone else who hits this as well - here is an expanded answer. This is what you need to "fix" things in your pom (until Eclipse fix things properly):
<!-- See https://stackoverflow.com/q/45870753 -->
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.1.1</version>
</dependency>
This pulls in eclipselink but excludes the javax.persistence dependency that it tries to pull in and replaces it with an earlier version of javax.persistence that doesn't have the signing issue.
Aside: javax.persistence version 2.2.0 is explicitly pulled in, in the pom fragment shown in the original question, despite already being a transitive dependency of eclipselink.
Explanation
Summary - the eclipselink artifact depends on javax.persistence and both contain classes that are in the package javax.persistence. However the javax.persistence jar is signed while the eclipselink one is not. So the Java runtime will complain, when loading a class from the package javax.persistence in the eclipselink jar, that it's lack of signing doesn't match with classes already loaded from the same package in the javax.persistence jar.
Details - if I put a breakpoint in java.util.concurrent.ConcurrentHashMap.putIfAbsent(K, V) with condition "javax.persistence".equals(arg0) then I see that javax.persistence is mapped to the following CodeSource value:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/javax.persistence/2.2.0/javax.persistence-2.2.0.jar [
[
Version: V3
Subject: CN="Eclipse Foundation, Inc.", OU=IT, O="Eclipse Foundation, Inc.", L=Ottawa, ST=Ontario, C=CA
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
...
I.e. javax.persistence-2.2.0.jar is signed by the Eclipse Foundation and contains classes in the package javax.persistence. This jar is pulled in when some part of my application (actually something deep in Spring logic) tries to load javax.persistence.EntityManagerFactory.
If I then put a breakpoint in java.lang.ClassLoader.checkCerts(String, CodeSource) on the throw new SecurityException line I then see that it hits this line when the passed in CodeSource is:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar <no signer certificates>)
I.e. eclipselink-2.7.0.jar also contain classes that are in the javax.persistence package but it is unsigned so a clash occurs that results in a SecurityException being thrown. This happens when something (also deep in Spring logic) tries to load javax.persistence.PersistenceUtil.
If I look at the output of mvn dependency:tree I see that this mismatch seems to be down to eclipselink itself - it is pulling in org.eclipse.persistence:javax.persistence:jar:2.2.0 itself. I.e. it isn't some clash with some other dependency:
[INFO] | \- org.eclipse.persistence:eclipselink:jar:2.7.0:compile
[INFO] | +- org.eclipse.persistence:javax.persistence:jar:2.2.0:compile
[INFO] | +- org.eclipse.persistence:commonj.sdo:jar:2.1.1:compile
[INFO] | +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] | \- org.glassfish:javax.json:jar:1.0.4:compile
I've logged this now at bugs.eclipse.org - see bug 525457.
To fix this issue, put in the correct JPA 2.2 compliant dependency for EclipseLink 2.7.x, in your maven pom file, as:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa</artifactId>
<version>2.7.1</version>
</dependency>
eclipselink.jar as such is designed as all-in-one bundle, not osgi enabled jar containing all partsof eclipselink project (ie sdo, oracle db specific stuff, dbws, nosql..) with ability to run with jpa api 2.0 on the classpath - at least in 2.x versions. In many cases this is not needed and proper components can be used instead, such as org.eclipse.persistence.jpa, org.eclipse.persistence.oracle etc. For the full list see ie: http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.persistence
This strange situation still seems to exist, in my case not using Maven, just trying to get a simple JPA example to run (and it is really frustrating if you need hours just to achieve that).
With 2.7.4 from January, this error occurs if you put the eclipselink.jar and jakarta.persistence_2.2.2.jar from the zip on the classpath.
In the end solution was to change order on the classpath: first the jakarta-persistence and only after that the eclipselink-jar.
So all javax.persistence classes are taken from jakarta-jar and not partly of the eclipselink-jar (if included there).
So I really wonder various things.
The eclipselink package should be all-in-one? But it is not. Some javax.persistence classes are contained. Others not - basic classes to be used in JPA code like EntityManager. Of course, together with the jakarta-jar included in the zip it is complete - but you may not use the two jars together with the "wrong" order on the classpath!? I really consider this a bug - or at least there should be a HUGE hint about this in the package then.
What is the org.eclipse.persistence.jpa-2.7.4.jar from Maven that is suggested here? It does not have the problems of the eclipselink.jar yes, not this error message. But then it also just seems not to include the Eclipselink JPA implementation, at least running with it I got error that persistence-unit referenced in code does not exist (same persistence.xml working with eclipselink.jar).
Strange situation.
My project was working on JDK-8, but stopped to work when I upgraded it to openJDK-11.
I solved it excluding the jpa-persistence module, and adding again on the version 2.2:
dependencies.create('org.eclipse.persistence:eclipselink:2.7.4') {
exclude module: "javax.persistence"
},
'javax.persistence:javax.persistence-api:2.2', //add it again, manually
'org.eclipse.persistence:org.eclipse.persistence.asm:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.antlr:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.moxy:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.core:2.7.4'
I fixed this by switching the order in which the jars appear in the classpath. In my case, I'm using Tomcat and had to modify catalina.properties to put javax before eclipselink.
Obinna's answer is correct; I guess that there was an issue with eclipselink 2.7.x –as George indicated. I had a similar issue when upgrading eclipselink, but it was just wrong artefacts. The initially described issue seems to be a result of externally referencing javax.persistence level - it is definitely not necessary.
Proper maven configuration can be found in eclipselink wiki:
https://wiki.eclipse.org/EclipseLink/Maven
I also run into this problem, with my case being a bit different, in that I am not using Maven. However, I place an answer here, as it might give people an idea about how to deal with this in their own situation. After all, the title is about this mismatch, in general, one sub-case being when using Maven.
I am using eclipselink in a NetBeans project. Initially, I was placing both the the eclipselink jar file (eclipselink-2.7.0.jar) and the needed org.eclipse.persistence jar files as external libraries to my project. Comments by Sergey and entreprenr above are what actually lead me to solve my problem. What I had to do was create a new library (Tools->Libraries->New Library...) which does not contain the eclipselink jar file (i.e. eclipselink-2.7.0.jar is not added in the library), only the specific org.eclipse.persistence jar files that are necessary for the project, e.g. org.eclipse.persistence.antlr-2.7.0.jar, org.eclipse.persistence.asm-2.7.0.jar, org.eclipse.persistence.core-2.7.0.jar, org.eclipse.persistence.jpa.modelgen.processor-2.7.0.jar, org.eclipse.persistence.jpa-2.7.0.jar, etc. I then added this library to my project and the exception vanished.
Of course, I also had to replace all org.eclipse.persistence jar files on my server with their 2.7.0 version and also replace the javax.persistence.jar with its 2.2.0 version (I use payara, so these are located under <payara_home>\glassfish\modules).
I'm using gradle in my project build and to solve the OP's problem, which I had as well, I finally used the following working setup.
dependencies {
testImplementation(group: 'org.eclipse.persistence', name: 'eclipselink', version: '2.7.4') {
exclude group: 'javax.validation', module: 'validation-api'
exclude group: 'org.eclipse.persistence', module: 'javax.persistence'
exclude group: 'org.eclipse.persistence', module: 'commonj.sdo'
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
testImplementation(group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4') {
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
}
Instead of "testImplementation" you can of course use any dependency type you want or need.
After reading Sergey's comment I've improved this by just using:
dependencies {
testImplementation group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4'
}
I think the last one is the best solution.
Because I could not find an answer for this problem when only using a Tomcat and this thread is often linked with this problem, I am going to post my solution here:
Since the signature is in the MANIFEST.MF you can change the signatures in the .jar files using 7zip or WinRAR to open them or simply delete them from the META-INF files of both .jar's and then import the changed files to your IDE.
A useful thread for the Signature-Mismatch-Problem is this thread: Java SecurityException: signer information does not match
I am am migrating project to dagger 1.2.2. I'd like to override some dependencies for functional tests. For that I included the dagger-compiler as a dependency of the androidTest-build(?) as well:
apt "com.squareup.dagger:dagger-compiler:$daggerVersion"
compile "com.squareup.dagger:dagger:$daggerVersion"
androidTestApt "com.squareup.dagger:dagger-compiler:$daggerVersion
Now the compiler complains that he cannot find a class (I guess because both builds now contain the transitive dependencies of dagger-compiler):
Error:Execution failed for task ':app:compileDebugAndroidTestJava'.
> java.lang.NoClassDefFoundError: javax/inject/Scope
Looking around github it seems the approach should work without manually excluding stuff.
Nevermind. Actually reading the whole buildfile helps alot.
Because of previous dependency-foo I had a directive that excluded the missing dependency explicitly:
configurations {
androidTestCompile.exclude(group:'javax.inject')
}
Removing that fixed it.