Develop Reference

Package 'org.pmml4s.model' is declared in module with an invalid name ('pmml4s.2.10')

I'm trying to use PMML4S to make predictions from an imported model from sklearn. I have the model in an xml file that I am trying to load into java using pmml4s. I am trying to follow this. However, I am having issues getting it to work: specifically, "Package 'org.pmml4s.model' is declared in module with an invalid name ('pmml4s.2.10')" . I am using IntelliJ as my IDE. Please let me know if I can provide other information/code. Any help is appreciated!
Error is here:
import org.pmml4s.model.Model;
Dependencies:
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>18.0.2</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-fxml</artifactId>
<version>18.0.2</version>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.pmml4s</groupId>
<artifactId>pmml4s_2.10</artifactId>
<version>0.9.16</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.36</version>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>doctor</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-math3</artifactId>
<version>3.6.1</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-text</artifactId>
<version>1.9</version>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>6.0.0</version>
</dependency>
</dependencies>

You used java 9 modules in your project and imported a library which was not converted to java 9 modules. Thus Java treats this library as an automatic module and derives module name from jar name. The jar name happens to be illegal.
See:
What is an automatic module?
You have 2 options:
Option 1: Dont use java9 modules
See:
Is there any need to switch to modules when migrating to Java 9 or later?
Option 2: Sanitize jar name
See:
Unable to derive module descriptor for auto generated module names in Java 9?
Scala Suffix Maven plugin looks like a tool designed precisely to solve your problem
Note that you need to require the automatic module in this approach:
How to use 3rd party library in Java9 module?

java.lang.AbstractMethodError: I get this exception when I am trying to initiate an outbound voice call using nexmo(vonage) API

My pom.xml for all the relevant dependencies. No other dependencies use the below dependencies internally.
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.9</version>
</dependency>
<dependency>
<groupId>com.sparkjava</groupId>
<artifactId>spark-core</artifactId>
<version>2.6.0</version>
</dependency>
<dependency>
<groupId>com.vonage</groupId>
<artifactId>client</artifactId>
<version>6.0.0</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-api</artifactId>
<version>0.11.0</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-impl</artifactId>
<version>0.11.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-jackson</artifactId>
<version>0.11.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>
Java Code to initiate outbound voice call using vonage SDK.
VonageClient client = VonageClient.builder().applicationId(APPLICATION_ID).privateKeyContents(PRIVATE_KEY).build();
Ncco ncco = new Ncco(TalkAction.builder(MESSAGE).voiceName(VOICE_TYPE).build());
CallEvent callEvent=client.getVoiceClient().createCall(newCall(TO_NUMBER,FROM_NUMBER, ncco));
Exception thrown when executing the code.
java.lang.AbstractMethodError: Receiver class
io.jsonwebtoken.impl.DefaultJwtBuilder does not define or inherit an
implementation of the resolved method 'abstract
io.jsonwebtoken.JwtBuilder signWith(java.security.Key,
io.jsonwebtoken.SignatureAlgorithm)' of interface
io.jsonwebtoken.JwtBuilder.
at com.nexmo.jwt.JwtGenerator.generate(JwtGenerator.kt:49) ~[jwt-1.0.1.jar:?]
at com.nexmo.jwt.Jwt.generate(Jwt.kt:44) ~[jwt-1.0.1.jar:?]
at com.nexmo.jwt.Jwt.generate$default(Jwt.kt:43) ~[jwt-1.0.1.jar:?]
at com.nexmo.jwt.Jwt.generate(Jwt.kt) ~[jwt-1.0.1.jar:?]
at com.vonage.client.auth.JWTAuthMethod.apply(JWTAuthMethod.java:43)
~[client-6.0.0.jar:6.0.0]
at com.vonage.client.AbstractMethod.applyAuth(AbstractMethod.java:127)
~[client-6.0.0.jar:6.0.0]
at com.vonage.client.AbstractMethod.execute(AbstractMethod.java:73)
~[client-6.0.0.jar:6.0.0]
at com.vonage.client.voice.CallsEndpoint.post(CallsEndpoint.java:57)
~[client-6.0.0.jar:6.0.0]
at com.vonage.client.voice.VoiceClient.createCall(VoiceClient.java:61)
~[client-6.0.0.jar:6.0.0]
at com.senpiper.core.listener.VoiceCallListener.listen(VoiceCallListener.java:37)
~[classes/:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]

The issue is the reference to:
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>
Deleteing this dependency will resolve your issue. This package is superseded by the three preceding it which are the modularized versions of that same package see v0.10.0 release notes for details the following from you POM file will suffice:
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-api</artifactId>
<version>0.11.0</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-impl</artifactId>
<version>0.11.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-jackson</artifactId>
<version>0.11.0</version>
<scope>runtime</scope>
</dependency>
The Vonage SDK is dependant on jjwt v0.10.5, the method that your app is choking on however was introduced in v0.10.0 - when the arguments got flipped around. Maven can be a tad quirky when it comes to handling copies of a dependency. In this case, because you are referencing 0.9.1 of jjwt explicitly it's pulling in an incompatible version. If I had to take a shot in the dark, I'd guess that the reference to the non modular jjwt package comes ahead of the other dependencies - which is why it's being pulled in and not the others.
Regardless - just remove the reference the old jjwt package - that will resolve your issue.

NoSuchMethodError: What version of Apache Xml Security do I need?

I was getting this exception
java.lang.NoSuchMethodError: org.apache.xml.security.utils.XMLUtils.decode
Then I updated my dependencies and moved on to another similar exception which I am unable to resolve for quite a while:
I am getting NoSuchMethodError when my module receives the request upon calling this method
WebServiceTemplate client = ...;
client.marshalSendAndReceive(req, new ActionCallback("http://samples/RequestOrder"));
it throws
java.lang.NoSuchMethodError: org.apache.xml.security.encryption.AbstractSerializer: method <init>()V not found
at org.apache.cxf.ws.security.wss4j.StaxSerializer.<init>(StaxSerializer.java:62)
the (at least I think) relevant part of my dependencies
<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.6.15</version>
</dependency>
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<version>3.0.9.RELEASE</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-security</artifactId>
<version>3.3.6</version>
</dependency>
I was looking at multiple versions of org.apache.xml.security.encryption and it doesn't look like any of those versions have such method. Any idea what would be the correct combination of versions?
as a sidenote I also found this library and thought that would be helpful , but it seems it is somewhat different than aforementioned <groupId>org.apache.ws.security</groupId>
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j</artifactId>
<version>2.3.0</version>
<type>pom</type>
</dependency>

I had similar issue and tried possible solutions online but to no avail.
Some of the documents suggested that dependency mismatch with other dependencies is key, like here.
In relation to this exact reported error, I kept on changing the version of the below dependency and finally reached this, which was the latest version as at the time this answer was posted.
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>2.1.4</version>
</dependency>
But remember to ensure that if you have the below dependency, exclude that of xmlsec :
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
</exclusion>
</exclusions>
</dependency>

Migrating application from RestEasy to Jersey

I am working on migrating an application from RestEasy implemenation to Jersey Implementation. The main problem I am facing is in the jars required for the CDI part.
While using resteasy, we are using the following 3 resteasy related jars
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-cdi</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
Now, to migrate it to Jersey, I am using the following jars in place of the resteasy jars.
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x-servlet</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>1.1</version>
</dependency>
Now when I try to deploy the EAR on the JBOSS server, I get the following error.
15:04:48,156 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.subunit."abc-ear.ear"."xyz-service-impl.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."abc-ear.ear"."xyz-service-impl.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "xyz-service-impl.war" of deployment "abc-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS016053: Service class org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider didn't implement the javax.enterprise.inject.spi.Extension interface
at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:48)
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:119)
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
... 5 more
As you can see from stack trace, the error that I am getting is org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider didn't implement the javax.enterprise.inject.spi.Extension interface
I downloaded the source of the required jar to see if the class in question implements that interface or not. Well, it does implement the Extension interface.
Right now I am not able find a solution for this error.
I have tried various permutation and combination of different jersey jars but couldn't find a fix for this.
I have ran out of ideas. Any help would be really appreciated.

Recently I've done quite similar migration (RESTEasy 3.0.8.Final -> Jersey 2.23.1), but my migration also included the abandonment of the WildFly server. So it's quite big difference.
You haven't included any information about used Weld version, so please do it as this is very important here.
Anyway, two tips from my side before you'll update your question:
There is a big chance that your error is caused by the EAR deployment. Because CDI and EAR archives sometimes don't play well together. Can you check what happen if you change your packaging to *.war?
If you don't have a very, very good reason to migrate to a non-built-in JAX-RS implementation when still using Java EE app server and CDI, please don't do it. It's a tough task.
Ps. JFYI amount of problems with Weld and App servers which I've encountered pushed me to abandon them wherever I can.
UPDATE
You said you are using Weld 1.1.23.FINAL - this is very important information. Jersey + Weld integration changed heavily since Jersey 2.15. Personally, I wasn't able to make it work without some newer Weld version (2.3.5 in my case) - probably because this combination isn't supported.
In your case, as you're using extremely old Weld version, I would advice you to try at most Jersey 2.14.
In Jersey 2.14, needed dependencies were different. Please remove jersey-cdi1x-servlet and try this instead:
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi</artifactId>
<version>2.14</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi-ban-custom-hk2-binding</artifactId>
<version>2.14</version>
</dependency>
<!-- is it needed for you?
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-core</artifactId>
</dependency>
-->
BTW: may I know why you are changing JAX-RS implementation inside JBoss?

I have migrated to latest versions last month and this works for me.
try this.
<properties>
<version.jersey>2.23.2</version.jersey>
<version.glassfish>2.4.0</version.glassfish>
</properties>
<dependencies>
<dependency>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>asm-all-repackaged</artifactId>
<version>${version.glassfish}</version>
</dependency>
<dependency>
<artifactId>hk2-utils</artifactId>
<groupId>org.glassfish.hk2</groupId>
<version>${version.glassfish}</version>
<exclusions>
<exclusion>
<artifactId>javax.inject</artifactId>
<groupId>javax.inject</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.0.1</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>${version.jersey}</version>
<exclusions>
<exclusion>
<groupId>org.glassfish.hk2</groupId>
<artifactId>osgi-resource-locator</artifactId>
</exclusion>
<exclusion>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>aopalliance-repackaged</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${version.jersey}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>${version.jersey}</version>
</dependency>
</dependencies>

You might be using wrong dependancies. Check this:
https://jersey.java.net/documentation/latest/modules-and-dependencies.html

Why is Gradle excluding required dependencies?

Environment: Linux, Artifactory, Java web apps, Gradle 2.12 with Spring dependency management plug-in and Flyway plug-in.
We are NOT using the Artifactory plug-in. We are just hitting it as if it were a generic maven repository.
Project is massive with something between 80 and 90 sub-projects. We have had several people working on migrating it over from Maven but there have been many headaches. We've beaten most of them but this particular series of knots is very close to sinking us.
Problems:
The build is not faster than Maven using --daemon and not --parallel. This seems pretty weird. Profiling shows that dependency resolution is taking a very long time.
Some aspect of the build is not stable. This is to say that we get various compiler issues when we try to build. This happens regardless of whether we use --parallel or not, although it happens to a greater degree with --parallel. It also happens regardless of local or remote dependencies. We suspect that it is related to some aspect of dependency resolution or perhaps as a result of unexpected exclusion behavior on the part of Gradle. Specifically, we get "Class def not found" and / or "missing symbol". Usually this seems to be related to a transitive dependency. If I put it in explicitly, the error goes away and I get a new one pertaining to a different transitive. I've experimented with putting them in as both transitive and as transitive = false.
Complicating matters, we have many BOMs. Perhaps 10? Some are ours and others belong to 3rd parties. Two or three are more than a page in length.
Without --parallel we can't seem to get the performance we need to justify the migration but we could, perhaps, survive that and wait for --parallel to finish incubating IF we could get it to build reliably. We've been cycling on --debug for about 2 weeks now but our shop is, naturally, inexperienced with Groovy and Gradle.
Clarification: It works about 30% of the time with --parallel and about 90% of the time without. If you build the specific project in question, using the full project path or changing to that sub-directory, there is no problem building.
From the --debug output, for example, I see:
...
-classpath
/development/.../build/classes/main
/development/.../build/resources/main
/home/someUser/.gradle/caches/modules-2/files-2.1/org.springframework/spring-context/4.1.7.RELEASE/8c6c02bcccfa23a74db59f7b7725e69e1af38f04/spring-context-4.1.7.RELEASE.jar
/development/.../build/libs/data-6.7.0-SNAPSHOT.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.hibernate/hibernate-core/4.2.18.Final/2b4c72104fe1910d368d766243f0d0ac2608e134/hibernate-core-4.2.18.Final.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/joda-time/joda-time/2.8.1/f5bfc718c95a7b1d3c371bb02a188a4df18361a9/joda-time-2.8.1.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/commons-lang/commons-lang/2.6/ce1edb914c94ebc388f086c6827e8bdeec71ac2/commons-lang-2.6.jar
/development/.../build/libs/pnq-orgmanagement-6.7.0-SNAPSHOT.jar
/development/.../build/libs/pnq-stuffmanagement-6.7.0-SNAPSHOT.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/com.pnq/pnq-someutils/6.7.0-SNAPSHOT/642a90ae7cc4f3f9b281184cacbfa1294f176df8/pnq-someutils-6.7.0-SNAPSHOT.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/com.eaio.stringsearch/stringsearch/2/44618501b2fb6b2d1bb851d00b264a6eaf1fc0b0/stringsearch-2.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.bouncycastle/bcprov-jdk15on/1.52/88a941faf9819d371e3174b5ed56a3f3f7d73269/bcprov-jdk15on-1.52.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/commons-collections/commons-collections/3.2.1/761ea405b9b37ced573d2df0d1e3a4e0f9edc668/commons-collections-3.2.1.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/commons-codec/commons-codec/1.10/4b95f4897fa13f2cd904aee711aeafc0c5295cd8/commons-codec-1.10.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.springframework/spring-beans/4.1.7.RELEASE/e52148e9671e2918a2172c9cf56b77bede2042ce/spring-beans-4.1.7.RELEASE.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/commons-validator/commons-validator/1.4.1/2231238e391057a53f92bde5bbc588622c1956c3/commons-validator-1.4.1.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.springframework/spring-orm/4.1.7.RELEASE/d8923bdffe631904899875e719d8b363bc3deaea/spring-orm-4.1.7.RELEASE.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.javolution/javolution-core-java/6.2.0rc3/5bae18008a0182d80155dbbe2c91d8907d2496d/javolution-core-java-6.2.0rc3.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.springframework/spring-tx/4.1.7.RELEASE/3465a5d3b24006d51482cf45abd13e347f64582a/spring-tx-4.1.7.RELEASE.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-api/1.6.1/6f3b8a24bf970f17289b234284c94f43eb42f0e4/slf4j-api-1.6.1.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/com.pnq/pnq-batchutils/6.7.0.2/9c025552239645478a759267748c73f3e1e43a47/pnq-batchutils-6.7.0.2.jar
/development/.../build/libs/pnq-mailutils-6.7.0-SNAPSHOT.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/com.pnq/pnq-utilities/6.7.0.2/d1e8ad707ebd2eddbb29eb0052c05b34acd98b46/pnq-utilities-6.7.0.2.jar
/development/.../build/libs/pnq-database-6.7.0-SNAPSHOT.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/com.twilio.sdk/twilio-java-sdk/3.3.9/133f7bde99aefae1df78ecd9787e5e60bc521ad2/twilio-java-sdk-3.3.9.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.apache.velocity/velocity/1.7/2ceb567b8f3f21118ecdec129fe1271dbc09aa7a/velocity-1.7.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/javax.mail/mail/1.4.1/8b7bc69010655425dabf091b51d1e90b4de36715/mail-1.4.1.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/org.apache.httpcomponents/httpclient/4.5/a1e6cbb3cc2c5f210dd1310ff9fcb2c09c0d1438/httpclient-4.5.jar
/development/.../build/libs/pnq-infoassembler-6.7.0-SNAPSHOT.jar
/development/.../build/libs/pnq-stufflookup-6.7.0-SNAPSHOT.jar
/home/someUser/.gradle/caches/modules-2/files-2.1/com.pnq/pnq-rcrtrlss/6.7.0-SNAPSHOT/58d6caa20da9035ce7b311f54915448c5bb903dc/pnq-wierdorules-6.7.0-SNAPSHOT.jar
/development/.../build/libs/pnq-cmanagement-6.7.0-SNAPSHOT.jar
/development/.../build/libs/pnq-translation-6.7.0-SNAPSHOT.jar
/development/.../build/libs/pnq-eutilities-6.7.0-SNAPSHOT.jar
/development/.../build/libs/pnq-control-6.7.0-SNAPSHOT.jar
/development/../database/build/libs/test-pnq-database-6.7.0-SNAPSHOT.jar
...
14:50:06.439 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder] junit:junit is excluded from com.project:project-enterprise-test:6.7.0.2(default).
...
st.java:3: error: package org.junit does not exist
14:50:06.481 [ERROR] [system.err] import static org.junit.Assert.assertEquals;
14:50:06.481 [ERROR] [system.err] ^
Note: A global search shows there are NO excludes for junit anywhere in the Gradle build. Also, what DON'T I see in the -classpath? Junit.
...but in the relevant build.gradle file I see:
testCompile ("com.project:project-enterprise-test")
The above is a BOM containing Maven dependencies:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc7</artifactId>
</dependency>
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<exclusions>
<exclusion>
<groupId>cglib</groupId>
<artifactId>cglib-nodep</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<exclusions>
<exclusion>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-integration</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</dependency>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-dbcp2</artifactId>
</dependency>
<dependency>
<groupId>org.fitnesse</groupId>
<artifactId>fitlibrary</artifactId>
</dependency>
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-bundle</artifactId>
</dependency>
<dependency>
<groupId>net.sf.dbfit</groupId>
<artifactId>dbfit</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-jexl</artifactId>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>com.springsource.org.apache.commons.io</artifactId>
</dependency>
<dependency>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</dependency>
<dependency>
<groupId>net.servicefixture</groupId>
<artifactId>servicefixture</artifactId>
</dependency>
</dependencies>
In the root build.gradle:
dependencyManagement {
...
imports {
mavenBom "com.project:project-enterprise-test:$bomversion"
}
...
}

It's really hard to help you if you don't include
related build.gradle snippets
the actual errors
For the dependency version mismatches, I suggest that you compare
mvn dependency:tree against gradle dependencyInsight to see what's different.
Maven and Gradle have different ways of dealing with multiple versions of the same dependency within the dependency hierarchy.
Maven uses a "nearest definition wins" strategy.
By default, Gradle will choose the latest version (or you can also define a custom ResolutionStrateegy)