I'm using gradle as the JavaFX plugin.
Everything works perfectly even after building and runnig the excecutable at distribution/, except with one class: CloseableHttpClient
For several purposes I create the following object like this:
CloseableHttpClient client = HttpClients.createDefault();
Running the program in the IDE is no problem, everything works fine. But if I build and try to run the .exe-File I get the following Throwable-StackTrace:
java.lang.NoClassDefFoundError: Could not initialize class org.apache.http.conn.ssl.SSLConnectionSocketFactory
at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:955)
at org.apache.http.impl.client.HttpClients.createDefault(HttpClients.java:58)
at ch.itcb.tools.lom.util.JsonSimpleUtil.http(JsonSimpleUtil.java:29)...
I really don't understand that. How can it be that just this class doesn't get found, but all my other classes do?
My build.gradle file:
apply plugin: 'java'
apply plugin: 'eclipse'
apply from: 'javafx.plugin'
sourceCompatibility = 1.8
version = '0.1'
jar {
manifest {
attributes 'Implementation-Title': 'LogoffManager',
'Implementation-Version': version
}
}
repositories {
mavenCentral()
}
dependencies {
compile fileTree(dir: 'lib', include: ['*.jar'])
compile 'ch.qos.logback:logback-classic:1.1.3'
compile 'org.apache.httpcomponents:httpclient:4.5.1'
compile 'com.googlecode.json-simple:json-simple:1.1'
compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
test {
systemProperties 'property': 'value'
}
uploadArchives {
repositories {
flatDir {
dirs 'repos'
}
}
}
Please write a comment if you need more information. Thx.
it's a good question, which I came across just now while researching examples of the many ways Java developers can end up with class path fun :-)
I started with a minimal version of your build.gradle (including only what's directly relevant), specifically:
plugins {
id 'java'
}
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
jar {
manifest {
attributes 'Main-Class': 'com.oliverlockwood.Main'
}
}
dependencies {
compile 'org.apache.httpcomponents:httpclient:4.5.1'
}
My 'Main' class, in this context, uses your code example, i.e.:
package com.oliverlockwood;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
public class Main {
public static void main(String[] args) {
CloseableHttpClient client = HttpClients.createDefault();
}
}
At this stage, I can run gradle clean build followed by java -jar build/libs/33106520.jar (my project was named after this StackOverflow question) and I see this:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/http/impl/client/HttpClients
at com.oliverlockwood.Main.main(Main.java:8)
Caused by: java.lang.ClassNotFoundException: org.apache.http.impl.client.HttpClients
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
This is subtly different from your error, but before we dig and reproduce that, let me emphasise something: both this error and the one you're seeing are caused at runtime when the classloader is unable to find a class that it needs. There's quite a good blog post here with some more details about the difference between compile-time classpath and runtime classpaths.
If I run gradle dependencies I can see the runtime dependencies for my project:
runtime - Runtime classpath for source set 'main'.
\--- org.apache.httpcomponents:httpclient:4.5.1
+--- org.apache.httpcomponents:httpcore:4.4.3
+--- commons-logging:commons-logging:1.2
\--- commons-codec:commons-codec:1.9
I added these manually one-by-one to my runtime classpath. (For the record, this isn't generally considered good practice; but for the sake of the experiment, I copied these jars to my build/libs folder and ran with java -cp build/libs/33106520.jar:build/libs/* com.oliverlockwood.Main. Interestingly enough, this wasn't able to reproduce your exact problem. To recap:
Without org.apache.httpcomponents:httpclient available at runtime, then we fail because the HttpClients jar is not found.
With org.apache.httpcomponents:httpclient:4.5.1 available at runtime, then your problem does not manifest - and I note that the class your build fails to find (org.apache.http.conn.ssl.SSLConnectionSocketFactory) is part of this same Apache library, which is very suspicious indeed.
My suspicion is then that your runtime classpath contains a different version of the Apache httpclient library. Since there's a whole lotta versions out there, I'm not going to test every single combination, so I will instead leave you with the following advice.
If you want to fully understand the root cause of your issue, then identify exactly which jars (including their versions) are present in your error-case runtime classpath, including any jars that are packaged inside yours if you're creating a fat jar (more on this in point 3). It'd be great if you shared these details here; root cause analysis usually helps everyone to understand better :-)
Where possible, avoid using dependencies in the manner of compile fileTree(dir: 'lib', include: ['*.jar']). Managed dependencies based on a repository such as Maven or JCenter are much easier to work with consistently than dependencies in a random directory. If these are internal libraries that you don't want to publish to an open-source artifact repository, then it may be worth setting up a local Nexus instance or similar.
Consider producing a "fat jar" instead of a "thin jar" - this means that all runtime dependencies are packaged in the jar that you build. There's a good Shadow plugin for Gradle that I'd recommend - with this in place in my build.gradle, and running gradle clean shadow, I was able to run java -jar just fine without needing to manually add anything to my classpath.
For Spring boot users, this can be solved with one line of code. I am using Gradle/Kotlin, so:
id("org.springframework.boot") version "2.5.5"
inside the plugins {} section of your build.gradle.kts
For more information visit the Spring Boot Gradle Plugin Reference Guide.
For my case, I turned on my InteliJ after 3 months, got some runtime errors like noclassdeffounderror. I have to *** refresh gradle ***, then the errors are gone.
Related
I'm writing Minecraft Plugin using IntelliJ IDEA Ultimate with gradle. I have added dependency org.spigotmc:spigot-api:1.13.2-R0.1-SNAPSHOT as compileOnly. During development, I noticed that gradle compiles my code in different way than IntelliJ does. For example, IntelliJ was unable to accept addPassenger on Boat, but gradle compiled it. In the opposite way, if I changed it into setPassenger, IntelliJ didn't mark it as error, but gradle failed to compile. I tried to invalidate caches, reimport, clean, even remove %userprofile%\.gradle directory, nothing helped. As a POC I changed compileOnly to compile and it worked well, IntelliJ and gradle compilation results were consistent. What's the reason?
Ok, I found the solution (and forgot about this question).
I had been using multiple dependencies, and one load another with older version that I loaded implicitly in my build.gradle. However, they weren't exactly the same dependencies, but parallel ones. So gradle could not choose higher version of one dependency. Solution was to exclude this one explicitly loaded dependency and everything worked well.
Before:
dependencies {
compileOnly 'com.sk89q.worldedit:worldedit-bukkit:7.0.1'
compileOnly group: 'org.spigotmc', name:'spigot-api', version: '1.15.1-R0.1-SNAPSHOT'
}
After:
dependencies {
compileOnly('com.sk89q.worldedit:worldedit-bukkit:7.0.1') {
exclude `org.bukkit:bukkit:1.15.1-R0.1-SNAPSHOT`
}
compileOnly group: 'org.spigotmc', name:'spigot-api', version: '1.15.1-R0.1-SNAPSHOT'
}
I'm using the approach from Gradle - extract file from depended jar to extact a .so file from inside a native JAR.
configurations {
special
}
dependencies {
special('org.jogamp.jogl:jogl-all:2.3.2:natives-linux-i586')
}
task extract(type: Copy) {
from({ zipTree(configurations.special.singleFile) })
include 'natives/linux-i586/*.so'
into "$buildDir/extracted"
}
This works fine, however it appears to break compilation of code that depends on org.jogamp.jogl:jogl-all:2.3.2, the non-native Java part.
TestJogl.java:1: error: package com.jogamp.opengl does not exist
import com.jogamp.opengl.GL;
The compilation fails if the project is built with clean extract build but not clean build
I've simplified the code to
import com.jogamp.opengl.GL;
public class TestJogl {
private GL gl;
}
and corresponding build.gradle
apply plugin: "java"
dependencies {
compile "org.jogamp.jogl:jogl-all:2.3.2"
}
I've isolated this issue to the usage of "flatDir" repo. The exact same project compiles fine when using mavenCentral(). Note using a legacy corporate network without artifactory or direct Internet access.
allprojects {
repositories {
flatDir {
dirs "$rootProject.projectDir/local-repo"
// contains jogl-all-2.3.2-natives-linux-i586.jar
// jogl-all-2.3.2.jar
}
}
}
I've managed to work around the issue by changing the dependency to explicity specify #jar, which should be implicit
compile "org.jogamp.jogl:jogl-all:2.3.2#jar"
The same problem occurs in both single and multi project layouts.
My analysis: This is a bug in Gradle. Somehow when using flatDir Gradle gets confused and thinks that the dependency has been setup, but uses the native JAR instead of the Java JAR.
Questions: Am I doing something wrong? Is this a bug? Is there another way to workaround it?
Environment: Gradle 3.5, JDK 1.8u144
I have been trying to find the correct settings for IntelliJ's annotation processing in order for it to co-exist with Gradle's build process.
Whenever I build from IntelliJ I cannot get it to recognise the generated sources from the gradle-apt-plugin.
My requirements for my project are:
Building between IntelliJ and Gradle should be seamless and not interfere with the process of each other
I need to use IntelliJ's Create separate module per source set option
I need to use IntelliJ's folder based structure
IntelliJ needs to be able to recognise and autocomplete AutoValue classes
Here are the steps for a MCVE in order to reproduce the issue with IntelliJ 2017.2.4 and Gradle 3.5:
Create a new Gradle project from IntelliJ
Check the Create separate module per source set option
Open build.gradle file:
Add the following plugins block:
plugins {
id 'java'
id 'net.ltgt.apt' version '0.12'
}
Add the following dependencies block
dependencies {
compileOnly 'com.google.auto.value:auto-value:1.5'
apt 'com.google.auto.value:auto-value:1.5'
}
Go to Settings → Build, Execution, Deployment → Annotation Processors
Check the Enable Annotation Processing
Create a class:
#AutoValue
public abstract class GeneratedSourcesTest {
static GeneratedSourcesTest create(String field) {
return new AutoValue_GeneratedSourcesTest(field);
}
public abstract String field();
}
On IntelliJ run Build → Build Project
Open the GeneratedSourcesTest class, on the static factory method, everything compiles fine but I get the error:
cannot resolve symbol ‘AutoValue_GeneratedSourcesTest’
How can I make the AutoValue_GeneratedSourcesTest class accessible from IntelliJ?
After importing your Gradle project under IDEA do the following steps:
Set annotation processing configuration as follows:
Run menu: Build - Build Project
Right click on each new generated folder and select: Mark Directory as - Generated Sources Root so it was marked as follows:
Add /generated to project's .gitignore file
That's a minimal viable configuration which will provide full IDE support for generated classes.
The drawback is, whenever Gradle project gets re-imported the generated folders will need be marked as Generated Sources Root again.
Perhaps this can be improved with adding these paths as source sets under build.gradle.
Sometimes it happens that IDEA modules lose their compiler output path settings in result of the above. It's sufficient to just set it back to their default folders.
The answers are (should be) in the README for the gradle-apt-plugin: https://github.com/tbroyer/gradle-apt-plugin
Namely, also apply the net.ltgt.apt-idea plugin.
Btw, I recommend delegating build/run actions to Gradle in IntelliJ. Sure it's a bit slower, but requires zero setup in the IDE and works reliably. That said, it should also work OK if you don't.
Just have your build.gradle with these and it works fine, no need of touching intellij, source set etc..
plugins {
id 'java'
id "net.ltgt.apt" version "0.20"
}
apply plugin: 'idea'
apply plugin: 'net.ltgt.apt-idea'
group 'abc'
version '1.0-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
compile "com.google.auto.value:auto-value-annotations:1.6.2"
annotationProcessor "com.google.auto.value:auto-value:1.6.2"
}
I didn't have to do anything to intellij using maven by adding the optional true tag.
<dependency>
<groupId>com.google.auto.value</groupId>
<artifactId>auto-value</artifactId>
<version>1.9</version>
<optional>true</optional>
</dependency>
I'm trying to compile an Android project unsuccessfully. The error message is:
Execution failed for task ':mobile:_compileAppDebug'.
java.lang.NoSuchMethodError: com.google.auto.common.MoreTypes.asTypeElements(Ljavax/lang/model/util/Types;Ljava/lang/Iterable;)Lcom/google/common/collect/ImmutableSet;
Here are my module's gradle dependencies in which I specify a number of libraries including google Auto:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':library')
compile 'com.google.dagger:dagger:2.0-SNAPSHOT'
provided 'com.google.auto.value:auto-value:1.0-rc1'
apt 'com.google.dagger:dagger-compiler:2.0-SNAPSHOT'
provided 'org.glassfish:javax.annotation:10.0-b28'
compile 'com.jakewharton:butterknife:6.1.0'
compile 'com.f2prateek.dart:dart:1.1.0'
}
When I looked at the dependencies I thought I just needed google auto value since that is where the missing method resides but adding the provided does not resolve the issue.
The project gradle file includes the retrolambda plugin
dependencies {
classpath 'me.tatarka:gradle-retrolambda:2.5.0'
classpath 'com.android.tools.build:gradle:1.0.1'
classpath 'com.jakewharton.sdkmanager:gradle-plugin:0.12.+'
classpath 'io.fabric.tools:gradle:1.+'
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
}
Can anyone help me identify which dependencies cause the compile error? Interestingly enough, when I copy the gradle files into an empty project everything runs fine.
Dagger 2.0-SNAPSHOT depends on an Auto SNAPSHOT which had an API change: https://github.com/google/dagger/issues/113
This is perfectly normal and acceptable thing for libraries which are under development. If you cannot tolerate an occasional broken build, do not depend on non-release versions in a manner that can change at any time without warning.
I ran in a similar issue. Some libary I'm using bundles Guava within the jar file.
Thus exluding this specific dependency from the apt configuration fixed the problem:
configurations {
apt.exclude module: 'artifactId-Of-Library'
}
I have a JPA/Hibernate project that implements a number of repository interfaces (I use DDD) and I have another project that tests the first one, by using JUnit 4. My IDE is Eclipse Luna. I learned later that I could made a single project with both runtime and testing code, but at this moment, I have them separated in those two projects.
Everything works perfectly so far.
Now, I decided to convert my test project in a Gradle project. After converting, I created this build.gradle file
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'application'
tasks.withType(JavaCompile) {
options.encoding = "UTF-8"
}
repositories {
mavenLocal()
mavenCentral()
}
jar {
baseName = 'dominio.hibernate.tests'
version = '0.1.0'
}
dependencies {
compile 'junit:junit:4.11'
compile 'org.hamcrest:hamcrest-all:1.3'
runtime fileTree(dir: '../dominio/build/libs', include: '*.jar')
compile fileTree(dir: '../dominio/build/libs', include: '*.jar')
runtime fileTree(dir: '../dominio.hibernate/build/libs', include: '*.jar')
compile fileTree(dir: '../dominio.hibernate/build/libs', include: '*.jar')
compile 'postgresql:postgresql:9.0-801.jdbc4'
compile 'org.hibernate:hibernate-core:4.3.6.Final'
compile 'org.hibernate:hibernate-c3p0:4.1.0.Final'
compile "javax.enterprise:cdi-api:1.0-SP1"
compile "javax.servlet:servlet-api:2.5"
runtime "org.jboss.weld:weld-core:1.0.1-SP1"
compile project(':Dominio')
compile project(':DominioHibernate')
}
task wrapper(type: Wrapper) {
gradleVersion = '1.11'
}
The compile works perfectly, but when I run the tests, iether in Eclipse or by Gradle, I have the folowing exception
javax.persistence.PersistenceException: No Persistence provider for EntityManager named unidades
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:61)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:39)
at dominio.hibernate.tests.HibernateUnidadeOrganizacionalRepositoryTests.setUp(HibernateUnidadeOrganizacionalRepositoryTests.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
... the rest of the stack
I stress that nothing changed in the Java code and it ran perfectly before Gradle came into the scene.
So, it appears that after converting the project to a Gradle one, persistence.xml is not being reachable anymore during the JUnit run, and I can't get the EntityManager instance I need to perform the tests.
I browsed a large number of posts about problems relating JUnit, resource files and Gradle, but no one of them could give me an idea about how to fix the problem.
Any ideas? Thanks in advance!
To successfully run tests that make use of Hibernate, Hibernate resources and related code have to placed in the same output directory:
sourceSets.main.output.resourcesDir = sourceSets.main.output.classesDir
This is only a problem for tests, as they have the output directories on their class path, rather than the Jar/War. (This avoids the need to build a Jar/War for running tests.)
Thanks to Peter Niederwiser answer and comments, this post in StackOverflow and some reading on Gradle documentation about Java plugin I was able to figure it out what was wrong and fix it. Detais below:
Peter suggestions on updating the resourceDir for both main and test source sets were done (see Peter's answer and his comments)
There was a Hibernate package missing for runtime environment; I updated the dependency block to add it:
dependencies {
...
compile 'org.hibernate:hibernate-entitymanager:4.3.6.Final'
runtime 'org.hibernate:hibernate-entitymanager:4.3.6.Final'
...
}
Only this two steps combined fixed my problem. The META-INF folder was copied to the right place and the (now present) Hibernate package was there to handle persistence.xml in order to create the EntityManager instance my testing code needed.