I'm writing a Java program - a plain command line program, not Android or anything like that - using Gradle, and trying to include Apache Commons IO. Per https://mvnrepository.com/artifact/commons-io/commons-io/2.6 I ended up with build.gradle like this:
apply plugin: 'application'
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
// https://mvnrepository.com/artifact/commons-io/commons-io
compile group: 'commons-io', name: 'commons-io', version: '2.6'
}
mainClassName = 'Main'
Gradle seems to download the package happily enough, but import statements referring to apache or commons get a not found error; this is true even when I run gradle build from the command line, omitting any IDE. What am I missing? (Previous similar discussions have been for Android or Eclipse projects; the instructions for those haven't worked here.)
I don't see any problems with your Gradle script, so at first glance, I'm thinking of two possible explanations:
you import a class that cannot be found in the artifact (e.g. a previous version of commons-io deprecated it and now they removed it)
your project's structure is set up incorrectly
I copied the exact contents of your script in a build.gradle file, created a src/main/java directory structure in the same directory, and wrote a small application Main.java under that directory with the following:
import org.apache.commons.io.IOCase;
public class Main {
public static void main(String[] args) {
System.out.println(IOCase.SENSITIVE.checkEndsWith("abcd1234", "1234"));
}
}
The code compiles successfully, so I need more context to troubleshoot your problem.
Related
After cleaning when i try to build gradle i get an error in the console saying:
package org.json does not exist import org.json.JSONObject;
cannot find symbol
symbol : class JSONObject
there are red marks in the java file at all places where jsonobject and json array exists.
I have put the folder web inf/lib that contains all the jar files inside the src/main/webapp directory that i have created.
currently the contents of my build.gradle file are:
/*
* This build file was auto generated by running the Gradle 'init' task
* by 'i2cdev001' at '14/11/18 3:11 PM' with Gradle 2.14.1
*
* This generated file contains a sample Java project to get you started.
* For more details take a look at the Java Quickstart chapter in the Gradle
* user guide available at https://docs.gradle.org/2.14.1/userguide/tutorial_java_projects.html
*/
// Apply the java plugin to add support for Java
apply plugin: 'java'
apply plugin: 'war'
// In this section you declare where to find the dependencies of your project
repositories {
// Use 'jcenter' for resolving your dependencies.
// You can declare any Maven/Ivy/file repository here.
jcenter()
}
// In this section you declare the dependencies for your production and test code
dependencies {
// The production code uses the SLF4J logging API at compile time
compile 'org.slf4j:slf4j-api:1.7.21'
// Declare the dependency for your favourite test framework you want to use in your tests.
// TestNG is also supported by the Gradle Test task. Just change the
// testCompile dependency to testCompile 'org.testng:testng:6.8.1' and add
// 'test.useTestNG()' to your build script.
testCompile 'junit:junit:4.12'
}
Note: Also in the project properties i am unable to see any jar files under the Web App Libraries in the java build path tab. I can see only access rules:no rules defined and native library locations:(none)
As your project is gradle project, Adding jar manually wont work.. You have to mention path where you have kept all your jar files in your build.gradle file.
Mention your jar file path in repository under flatDir {}:
repositories {
jcenter()
flatDir {
dirs 'libs'
}
}
Then you have to add which jar from that folder you have mentioned above (ie libs)
dependencies {
compile 'gson-0.1.0'
}
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 a created a simple java "echo" application that takes a user's input and shows it back to them to demonstrate the issue. I can run this application without trouble using IntelliJ's internal "run" command, and also when executing the compiled java file produced by gradle build. However, if I try to execute the application using gradle run, I get a NoSuchElementException thrown from the scanner.
I think gradle or the application plugin specifically is doing something strange with the system IO.
Application
package org.gradle.example.simple;
import java.util.Scanner;
public class HelloWorld {
public static void main(String args[]) {
Scanner input = new Scanner(System.in);
String response = input.nextLine();
System.out.println(response);
}
}
build.gradle
apply plugin: 'java'
version '1.0-SNAPSHOT'
apply plugin: 'java'
jar {
manifest {
attributes 'Main-Class': 'org.gradle.example.simple.HelloWorld'
}
}
apply plugin: 'application'
mainClassName = "org.gradle.example.simple.HelloWorld"
sourceCompatibility = 1.5
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.11'
}
Any ideas how to make this application work using gradle run?
You must wire up default stdin to gradle, put this in build.gradle:
run {
standardInput = System.in
}
UPDATE: 9 Sep 2021
As suggested by nickbdyer in the comments run gradlew run with --console plain option to avoid all those noisy and irritating prompts
Example
gradlew --console plain run
And if you also want to completely get rid of all gradle tasks logs add -q option
Example
gradlew -q --console plain run
In addition to the accepted answer: If you who are using the Gradle Kotlin DSL instead of the normal Groovy DSL, you have to write the following:
tasks {
run {
standardInput = System.`in`
}
}
Additional note: I had a similar problem in a Spring Boot application. There, I had to modify the bootRun task instead of the run task.
I'm learning to use Gradle with Kotlin DSL and what worked for me was answered here before.
// build.gradle (Groovy syntax)
run {
standardInput = System.in
}
// build.gradle.kts (Kotlin syntax)
tasks.named<JavaExec>("run") {
standardInput = System.`in`
}
The solution provided by #MarkusWeninger didn't worked for me.
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.
I am trying to import a sibling project tom-commons. My project budget_assistant needs tom-commons as a dependency, and they are both in the same workspace folder, not nested. It works fine in Intellij IDEA and the command line. But Eclipse does not seem to like it.
I don't think it is liking the ".." relative path and Eclipse must think it is a folder nested under my project. Is there a way to resolve this dependency into an absolute URL?
Here is my settings.gradle
include ':..:tom-commons'
And here is my build.gradle
repositories {
mavenCentral()
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
dependencies {
compile group: 'com.google.guava', name: 'guava', version: '18.0'
compile 'org.xerial:sqlite-jdbc:3.8.7'
compile 'net.jcip:jcip-annotations:1.0'
compile 'joda-time:joda-time:2.7'
compile project(':..:tom-commons')
}
sourceSets {
main.java.srcDir "src/main/java"
}
jar {
from configurations.compile.collect { entry -> zipTree(entry) }
}
The problem is that you are implicitly creating a project called ":.." and the Gradle tooling API directly reflects that in its project model as an "EclipseProject" who's name is "..". But. ".." is not a valid name for a project in an Eclipse workspace which causes the exception.
I still think this is a bug, in a sense. As we can put some blame on both Gradle tooling API for returning something illegal; and the tooling for not handling this 'junk' data more gracefully.
But really, I think you do not want a ":.." project. Rather you just want a ":ChildA" and ":ChildB" project which are direct children of ":" (in terms of project hierarchy), but are located as siblings in terms of where they reside on disk.
This kind of layout is most easily accomplished with 'includeFlat' (see Gradle docs) in settings.gradle.
In settings.gradle:
includeFlat 'ChildA','ChildB'
In build.gradle refer to children as ":ChildA" and ":ChildB" e.g:
dependencies {
compile project(':ChildA')
compile project(':ChildB')
}
See my changes to your sample on github.