Getting exception while gradle/gradlew build. Build without test cases is successful. This happening when I updated the gradle to 6.0.1
Works fine for gradle 5.6/6.2 version.
Could not write standard input to Gradle Test Executor 2.
java.io.IOException: The pipe is being closed
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at java.base/java.io.FileOutputStream.write(FileOutputStream.java:348)
at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
at org.gradle.process.internal.streams.ExecOutputHandleRunner.forwardContent(ExecOutputHandleRunner.java:68)
at org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:53)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.base/java.lang.Thread.run(Thread.java:835)
Error: Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain
Caused by: java.lang.ClassNotFoundException: worker.org.gradle.process.internal.worker.GradleWorkerMain
FAILURE: Build failed with an exception.
I just had this happen, and found that stopping the gradle daemon resolved it for me:
gradle --stop
or
./gradlew --stop
depending on your setup (the daemon is relaunched when you attempt to build again).
I encountered this error and the one method I found was dump the whole $HOME/.gradle cache and then rebuild the project.
Starting/Stopping IntellijIDEA and/or rebuilding did not help.
You know you have jumped the complexity shark somewhere when running lowly test cases starts to fail for obscure reasons.
Granted, this happened after a machine crash. But still..
If its a windows system, then try deleting the .gradle folder from the user directory and try to build the gradle. This should solve the issue
Related
IntelliJ fails to import my Gradle project.
The build window shows that the demon gets started on the right side, and on the left side it just displays
<project-name> failed <timestamp>
And indeed no dependencies get resolved, source folders don't get set.
How do I debug/fix this?
The first step should be to build the project on the command line and make sure it works.
Then locate the log file of IntelliJ: Help -> Show Log in Finder does it for me on Mac OS, I guess there is something similar on other platforms.
My log showed:
2021-03-16 11:08:31,370 [222013096] INFO - .project.GradleProjectResolver - Gradle project resolve error
org.gradle.tooling.GradleConnectionException: Could not run phased build action using connection to Gradle distribution 'https://services.gradle.org/distributions/gradle-6.8.3-bin.zip'.
at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:55)
at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:43)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:69)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.gradle.launcher.daemon.client.DaemonConnectionException: The newly created daemon process has a different context than expected.
It won't be possible to reconnect to this daemon. Context mismatch:
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/Users/jschauder/.sdkman/candidates/java/current,daemonRegistryDir=/Users/jschauder/.gradle/daemon,pid=981,idleTimeout=null,priority=NORMAL,daemonOpts=-Dfile.encoding=UTF-8,-Duser.country=GB,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=ad74fb8f-4b76-4109-9780-e222fddedd94,javaHome=/Users/jschauder/.sdkman/candidates/java/8.0.282-zulu/zulu-8.jdk/Contents/Home,daemonRegistryDir=/Users/jschauder/.gradle/daemon,pid=89910,idleTimeout=10800000,priority=NORMAL,daemonOpts=-Dfile.encoding=UTF-8,-Duser.country=GB,-Duser.language=en,-Duser.variant]
The important part is:
Wanted: DefaultDaemonContext[uid=null,javaHome=/Users/jschauder/.sdkman/candidates/java/current,daemonRegistryDir=/Users/jschauder/.gradle/daemon,pid=981,idleTimeout=null,priority=NORMAL,daemonOpts=-Dfile.encoding=UTF-8,-Duser.country=GB,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=ad74fb8f-4b76-4109-9780-e222fddedd94,javaHome=/Users/jschauder/.sdkman/candidates/java/8.0.282-zulu/zulu-8.jdk/Contents/Home,daemonRegistryDir=/Users/jschauder/.gradle/daemon,pid=89910,idleTimeout=10800000,priority=NORMAL,daemonOpts=-Dfile.encoding=UTF-8,-Duser.country=GB,-Duser.language=en,-Duser.variant]
I.e. the gradle demon runs with a different JDK than what IntelliJ expects.
To fix this you
go into the preferences of Intellij,
search for "gradle"
And locate the "Gradle JVM" setting and use the JDK path from the "Actual" line in the logs. In my case /Users/jschauder/.sdkman/candidates/java/8.0.282-zulu/zulu-8.jdk/Contents/Home
After that importing the project worked just fine.
I'm trying to upgrade an existing project from gradle 6.5.1 to 6.6.
But when I build, it fails with an error:
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 1.116 secs.
The client will now receive all logging from the daemon (pid: 122). The daemon log file: /home/****/.gradle/daemon/6.6/daemon-122.out.log
Starting build in new daemon [memory: 519.0 MB]
Using 1 worker leases.
Starting Build
Compiling initialization script '/home/****/agent/workspace/Enrich_build_PR-41#tmp/artifactory/init-artifactory449129576487257952gradle' using SubsetScriptTransformer.
FAILURE: Build failed with an exception.
* What went wrong:
Failed to create Jar file /home/****/.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok.
> Prefix string too short
Running with --debug, the only thing that looks relevant is:
020-10-05T16:38:54.631+0000 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Selected match ok from candidates [ok] for {org.gradle.dependency.bundling=external, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}
Which seems like an internal gradle issue. How can I fix or avoid this error?
(I also tried 6.6.1 and have the same problem)
It happens when I run "./gradlew help" as well, so it shouldn't be related to my build config.
The stacktrace looks like:
* Exception is:
org.gradle.api.GradleException: Failed to create Jar file /home/****/.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok.
at org.gradle.internal.classpath.ClasspathBuilder.jar(ClasspathBuilder.java:47)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.transform(InstrumentingClasspathFileTransformer.java:76)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.transform(InstrumentingClasspathFileTransformer.java:70)
at org.gradle.internal.classpath.DefaultCachedClasspathTransformer$TransformFile.lambda$schedule$0(DefaultCachedClasspathTransformer.java:261)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.IllegalArgumentException: Prefix string too short
at org.gradle.internal.classpath.ClasspathBuilder.buildJar(ClasspathBuilder.java:53)
at org.gradle.internal.classpath.ClasspathBuilder.jar(ClasspathBuilder.java:45)
... 6 more
Your issue seems to be related to artifactory plugin
Check https://github.com/jfrog/jenkins-artifactory-plugin/issues/349
Quick Fix
Recommend to downgrade to Gradle 6.5 to resolve the issue.
Further Details / Possible Cause
While I don't know the root cause of why this happens, I get the same 'Prefix string too short' error, in Gradle 6.6.1.
And in particular, this is my exact error message, from a Mac:
Failed to create Jar file /Users/****/.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok.
Since the 'prefix' error came from Java, I looked at my Java install thinking that might be the problem. In my case Java was many versions behind, so I upgraded to 8u261 however that didn't seem to change anything.
For how it starts in our case:
User kicks off Jenkins job for Gradle
Jenkins job fails specifically for being unable to create the file in the cache directory. And the number actually is the same each time for the cache too; it's always '.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok' and not a different number. So it's almost like that is statically set from somewhere.
So focusing on that error, I came across this similar-ish prefix error, for a Java issue. While this doesn't fully answer the issue we see, it does help explain why it could be a 'legitimate' error as it thinks the file name is less than 3 characters.
https://stackoverflow.com/a/48806741/14403001
So it feels like it's interpreting the end of that string as being the file name. Namely it might think that ok at the end of the path is actually a filename, and being less than 3 characters it sends the 'Prefix string too short' error. Keep in mind this is speculation and I don't know if this is actually the cause or not.
We happened to have another Mac that was running Gradle 6.5 that was working fine with the exact same Jenkins job. So we downgraded from Gradle 6.6.1 to 6.5 to match the other and are back working like before.
Since we used Mac, Brew didn't actually have an older version to roll back to. So I was forced to uninstall gradle via brew, then follow the steps below to install and point to an older version of Gradle.
Hoping it's easier for you via yum/apt to downgrade than it was for myself.
https://gradle.org/install/#manually
I have the following error (PLEASE NOTE the jar it says it could not find is different from the location jar name in this error...weird)...
* What went wrong:
A problem occurred evaluating project ':webserver:webpiecesServerBuilder:templateProject:WEBPIECESxAPPNAME'.
> Could not resolve all files for configuration ':webserver:webpiecesServerBuilder:templateProject:WEBPIECESxAPPNAME:runtime'.
> Could not find micrometer-core.jar (io.micrometer:micrometer-core:1.4.0-SNAPSHOT:20200320.152130-173).
Searched in the following locations:
https://repo.spring.io/libs-snapshot/io/micrometer/micrometer-core/1.4.0-SNAPSHOT/micrometer-core-1.4.0-20200319.235509-170.jar
A snapshot of the current contents of directory(in case this post last to tomorrow and a new snapshot is there) is the following...
I have no idea why it can't find 1.4.0-SNAPSHOT since my gradle file is simple and the dependency is simply
'io.micrometer:micrometer-core:1.4.0-SNAPSHOT'
I think it's a gradle daemon bug or something. I did rm -rf ./gradle/cache and then it broke with an exception
Caused by: java.lang.NoClassDefFoundError: build_a6ssp86bmi79bk936w466ea1t$_run_closure5$_closure11
at build_a6ssp86bmi79bk936w466ea1t$_run_closure5.doCall(/Users/dean/workspace/orderly/dataapi-all/dataapi/build.gradle:111)
at org.gradle.util.ClosureBackedAction.execute(ClosureBackedAction.java:71)
at org.gradle.util.ConfigureUtil.configureTarget(ConfigureUtil.java:154)
at org.gradle.util.ConfigureUtil.configureSelf(ConfigureUtil.java:130)
at org.gradle.api.internal.AbstractTask.configure(AbstractTask.java:587)
at org.gradle.api.internal.AbstractTask.configure(AbstractTask.java:91)
at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:103)
at org.gradle.api.internal.DefaultNamedDomainObjectCollection$ContainerElementsDynamicObject.tryInvokeMethod(DefaultNamedDomainObjectCollection.java:541)
at org.gradle.internal.metaobject.CompositeDynamicObject.tryInvokeMethod(CompositeDynamicObject.java:98)
So then I killed the gradle daemons and voila, it's working again.
When I run ./gradlew I get
Exception in thread "main" java.lang.NoClassDefFoundError:
org/gradle/wrapper/GradleWrapperMain Caused by:
java.lang.ClassNotFoundException: org.gradle.wrapper.GradleWrapperMain
at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:190) at
java.lang.ClassLoader.loadClass(ClassLoader.java:306) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at
java.lang.ClassLoader.loadClass(ClassLoader.java:247)
My project compiles using the Android Studio but stopped compiling from command line
Probably something went bad. The solution:
Install gradle: brew install gradle
Regenerate wrapper: gradle wrapper
See https://github.com/drone/drone/issues/256
My .gitignore had *.jar in it, so I wasn't getting all the jars I needed in my repository.
I had the same, or similar, problem when trying to build my app from command line, but with an exception thrown for 'java.lang.ClassNotFoundException: com.sun.tools.javac.util.Context' which did not happen when building within Android Studio. I found out that AS brings along it's own JRE and I resolved the issue by setting 'JAVA_HOME' to the AS JRE path. In my case it turned into:
$ JAVA_HOME=/opt/android-studio/jre ./gradlew build
You can find this path under 'File' -> 'Project Structure' -> 'SDK Location', see screenshot.
I hit this issue when I have a directory with a ":" (no quotes, just a colon) in it.
This was on a linux machine.
Before:
"my:directory"
as in
/Users/me/projects/project1/my:directory/
then i renamed it to
/Users/me/projects/project1/my_directory/
and the error went away.
I have problems with one job on my Jenkins server.
It fails during pom parse with this message:
Parsing POMs
Modules changed, recalculating dependency graph
[workspace] $ java -Xmx512m -XX:MaxPermSize=256m -Djava.awt.headless=true -cp /opt/edb/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/opt/apache/maven3/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /opt/apache/maven3 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.17.jar /opt/edb/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar 55430
<===[JENKINS REMOTING CAPACITY]===>channel started
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven [java, -Xmx512m, -XX:MaxPermSize=256m, -Djava.awt.headless=true, -cp, /opt/edb/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/opt/apache/maven3/boot/plexus-classworlds-2.4.jar, org.jvnet.hudson.maven3.agent.Maven3Main, /opt/apache/maven3, /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.17.jar, /opt/edb/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar, 55430] failed
at hudson.remoting.Channel.call(Channel.java:673)
at hudson.maven.ProcessCache$MavenProcess.<init>(ProcessCache.java:112)
at hudson.maven.ProcessCache.get(ProcessCache.java:231)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:704)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
at hudson.model.Run.execute(Run.java:1516)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: java.lang.Error: Failed to deserialize the Callable object.
Caused by: java.lang.IndexOutOfBoundsException: Index: 1997078527, Size: 0
I have tried creating a new build, no luck
Building locally works fine
All other similar jobs work fine
I'm running letest jenkins (1.489)
Any ideas?
Hard disk is full.
Try to restart.
Maybe the workspace is corrupted and on your pom.xml is not readable. Have to try to clean the workspace for this specific job ?
This issue was fixed for me by setting the correct version Java version in the PATH (as required in the pom.xml) - See https://issues.jenkins-ci.org/browse/JENKINS-5519