I am new at Docker and trying to build and run my own container with Spring Boot Application. It runs on Kotlin and Gradle.
I have built the image with simply this command, provided by gradle with spring boot plugin (id("org.springframework.boot") version "2.7.0-SNAPSHOT")
gradlew bootBuildImage
As a result i am getting this. Here are the logs: https://pastebin.com/xMW82vcw
The problem is, while trying to run my built image i am getting this error.
C:\projects\monetka-app>docker run docker.io/library/monetka-app:0.0.1-SNAPSHOT
Setting Active Processor Count to 6
unable to determine class count
unable to walk /workspace
unable to open ZIP /workspace/META-INF/licenses/client-2.1.jar
read /workspace/META-INF/licenses/client-2.1.jar: is a directory
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/memory-calculator': exit status 1
Here are the docker images i have locally
in docker desktop.
My gradle version is 7.4.1, and JDK in use is 17.
When you run gradlew bootBuildImage, you're using Cloud-Native buildpacks to generate the image. This is a bug in a tool installed by the buildpack.
The Java Cloud-Native buildpack will install a tool called memory-calculator. This tool runs prior to your application starting up and sets up all the JVM memory flags that are required to keep the JVM from going past the defined memory limit you set. For example, if you set the memory limit of your container to be 1G, the memory calculator will adjust settings like -Xmx accordingly.
To do this, the memory calculator needs to know how many class files you have in your application, so it searches for them. This process is failing because it sees something with an extension of .jar and so it's trying to read the number of class files in that JAR, however, what it's seeing META-INF/licenses/client-2.1.jar isn't actually a JAR. It's a directory.
I opened a bug report for you here: https://github.com/paketo-buildpacks/libjvm/issues/160
If you are able to remove the file META-INF/licenses/client-2.1.jar (or change so it doesn't have a .jar extension) you should be able to work around this until we can resolve the issue.
I have a gradle task (type - exec). In this task I start a WildFly server using a standart bat file (standalone.bat). The war file is already in deployments beforehand, so the server starts up and everything works fine.
The problem appears when I need to debug the actual application on the server. Running the gradle task in a debug mode doesn't help, as it can only debug the actual gradle task itself and not the application that it starts.
I know, there is a solution to this problem using an additional configuration that would allow me to debug a remote java application. However, the goal for me right now is to move eveything onto gradle tasks and not have any configurations set up in my IDE.
I need to be able to run a gradle exec task that would start up my server and than to debug whatever application it deploys. Is there a way to do this? Thank you in advance.
Note: I've never used Wildfly
Ultimately you'll want to edit standalone.bat so that you include an additional arguments to the java.exe invocation. Take a look inside standalone.bat many applications include a line commented out that you can uncomment to enable debugging.
Eg sample argument to add to the java.exe call
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044
You may wish to take a copy of standalone.bat which you call standalone-debug.bat which you invoke via gradle
Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
For me, killing the Gradle daemon (gradle --stop) really helped and fixed the issue.
Try setting your GRADLE_USER_HOME variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch/mkdir anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~ home directory (gradle_2_3_cache). This will help me in case I have another job/build run running on the same Slave machine but with a different Gradle version for ex: 2.5 etc version and if I want the .gradle cache for 2.3 and 2.5/x version in separate folders.
NOTE: When using parallel section within Jenkinsfile, it's best to avoid Gradle greatness (i.e. using same Gradle's cache i.e. using same GRADLE_USER_HOME) as otherwise, you'll land into a mine of interesting issues as listed here: Jenkins - java.lang.IllegalArgumentException: Last unit does not have enough valid bits & Gradle error: Task 'null' not found in root project
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
Restarting the machine solved the issue.
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew, gradlew.bat and gradle/wrapper/*) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
I got the same error, got rid of it by using the correct version of Java / JDK. I was trying to build a Java 8 project with the Java 11 JDK. Check which version of Java JDK you are using.
To develop projects with different Java versions in parallel I now use jEnv to manage the different JDK versions: http://www.jenv.be/
This is a permission issue.
do a
gradle wrapper --stacktrace
you should see something like this
Failed to create parent directory '/home/cloud_user/my-project/gradle' when creating directory '/home/cloud_user/my-project/gradle/wrapper'
the user, cloud_user, has no permission to the directory
make cloud_user owner of the folder
sudo chown -R cloud_user:cloud_user /home/cloud_user/my-project/
I got this error when running code in IntelliJ Idea, and
gradle --stop
really not helped, as it said that "No Gradle daemons are running."
But simple kill of all gradle processes helped:
ps aux | grep gradle
kill -9 $PID
Permission issue. This fixed the issue for me:
sudo chown -R $USER dir
For me this was to do with Java versions. I have Java 10 installed and as the default Java on my system. Setting a JAVA_HOME pointing at Java 8 was sufficient for the project (graphql-spring-boot) to build.
If using the "Invoke Gradle script" build step, click on Advanced to reveal additional options. Locate "Force GRADLE_USER_HOME to use workspace" and check it.
If anyone is still struggling with this, my issue was caused by Microsoft preventing Java from running due to Controlled Folder Access security restrictions.
I didn't get the popup notification since my computer is set to Do Not Disturb Mode. Once I allowed access, Gradle ran fine.
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME did not work. I had to change the filesystem to be read/write.
You Just Have to Run it under the super user (sudo ....) it works for me
If you run Docker-in-Docker and mount the project directory from docker host directly to docker container:
-v ${PWD}:/path_to_project -w /path_to_project
the owners are different and docker container user (either gradle or root) can't override/delete ./buildSrc/build or ./build/
One of the fixes - copy the sources inside the container to temporary directory and build there.
Smth like this (first mounted to project, but then copied to project-copy to "decouple" with the host system real files and run the build in the copy):
docker run -v "${PWD}":/home/gradle/project -w /home/gradle/project-copy \
--rm \
--entrypoint sh \
gradle:5.5.1-jdk11 \
-- -c "cp -r -T /home/gradle/project ./ && ./gradlew build"
In my case I had bad credentials to private Maven repository. JIdea does not show the inner exception but running gradle build reveals the problem immediately.
I used a Gradle project in Eclipse, Eclipse's Gradle was giving that error. When I installed NetBeans and its Gradle Plugin, the problem has gone, project was building okay. Another way to circumvent this error was using commandline ./gradlew , project also built successfully.
It seems that Eclipse's era is over, they appear to be unable to follow the progress.
This can happen if you run Gradle commands from separate terminals at the same time - I assume Gradle somehow locks ~/.gradle when it is running to prevent any problems.
I had that same error, while running gradle with java 14 (openjdk) as my default java implementation. Setting default java back to java 8 solved the issue
sudo update-alternatives --auto java
just run (taskkill /im java.exe /f) in command
In my case the error was different but I landed here, my error was:
Could not create service of type ExecutionHistoryStore using ExecutionGradleServices.createExecutionHistoryStore().
> Timeout waiting to lock execution history cache (/Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 94001
Owner Operation: unknown
Our operation:
Lock file: /Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory/executionHistory.lock
It happens when you try to run flutter run from two separate terminals.
So I solved it by executing cd <projectPath> && flutter run from the active terminal which I was using first.
Basically, while executing some Gradle command, in this case building an android file, the terminal locks down some Gradle PID, so either you stop them or just simply use that terminal.
in my case manual removing the .gradle and .idea folders helped me
you can find them in the Android Studio if Project view selected
after this just clean and rebuild app
kill -9 'pid' solved the issue. pid can be found in the error log
To fix this issue, restarting your PC is the main solution
I got the same issue and for me worked below command.
./gradlew --stop
After that restart my system and wipe data of simulator and run again everything works fine.
I have a Spring Boot project with gradle build tool. The JDBC url, username and password are kept in a property file which is not part of application it's a external property file, the path of the property file is taken from system properties as follows.
export _JAVA_OPTIONS=-DdatabaseConfiguration=db.properties
It is working if I run the application from terminal using gradle bootRun, but when I try to run from Intellij IDEA 13 gradle tasks its not working, the property value is null.
I tried the VM options in Run/Debug Configuration as in the below screen shoot its not working either
How can the JAVA_OPTIONS can be set in Intellij IDEA 13 gradle tasks.
This is because every time you use the Gradle tool window to kick off tasks in IntelliJ, it creates/overwrites the launch configuration for that task.
Basically, I've had to run from the Gradle tool window just once. Then I go into the failed Launch Config (shown in question) and enter the system property in the VM options. From there on out, I need to use that Launch Config to execute the task instead of the Gradle tool window.
Update: Even better solution:
Preferences->Build, Execution, Deployment->Build Tools->Gradle->Gradle VM options
Add your system properties there (i.e. -Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk)
Doing this will keep them from getting overwritten/lost in the Launch configs that the Gradle tool window generates.
Another thing to note is that using the Gradle tool window causes the commands to be run without access to Environment Variables. This can cause a lot of problems with builds that depend on these env vars.
I ran into this today with the appengine-gradle-plugin and had to put
-Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk
in the VM options because it was not seeing the env vars. From the command line, it picks up the env vars and works fine. This worked for my appengineRun task.
But it does not work for appengineUpdate since that gives another error caused by lack of env vars: Toolkit not found: apple.awt.CToolkit