I am trying to upgrade my Android Gradle plugin from 4.1.3 to 7.0.4 also lint version to 30.0.4
I am using Gradle version 7.3.3
My Gradle daemon crashes now while running lint target on CI process with error
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
Here is my gradel.properties file.
I tried various options android.experimental.runLintInProcess, android.experimental.lint.heapSize
discussed in this issue, without success.
https://issuetracker.google.com/issues/178631052
Has anyone seen this issue
org.gradle.jvmargs=-Xmx8g -Xms512M -XX:MaxPermSize=1024m -Dkotlin.daemon.jvm.options="-Xmx8g" -XX:+HeapDumpOnOutOfMemoryError -XX:+UseParallelGC -XX:MaxMetaspaceSize=1g -XX:+UnlockExperimentalVMOptions -Dfile.encoding=UTF-8
# When set to true, Gradle will try to reuse outputs from previous builds
org.gradle.caching=true
# Enables new incubating mode that makes Gradle selective when configuring projects
org.gradle.configureondemand=true
# When configured, Gradle will run in incubating parallel mode
org.gradle.parallel=true
# When configured, Gradle will use a maximum of the given number of workers
# 4 is good for a max for CI and running junit tests in parallel
org.gradle.workers.max=4
# Allowing to avoid Kotlin recompilation when the changes in Java do not affect Kotlin code
kotlin.incremental.usePreciseJavaTracking=true
android.useAndroidX=true
android.enableJetifier=true
android.uniquePackageNames=true
kapt.use.worker.api=true
org.gradle.unsafe.watch-fs=true
#https://issuetracker.google.com/issues/178631052
#android.experimental.runLintInProcess=false
#android.experimental.lint.heapSize=1G
It's OOM issue with Gradle Daemon. Setting these 6 bits in application.properties should work fine.
org.gradle.jvmargs=-Xmx8g
kotlin.daemon.jvmargs=-Xmx8g
org.gradle.caching=true
org.gradle.parallel=true
org.gradle.daemon=true
android.enableJetifier=true
The AGP 7.0.x reqire Gradle version 7.0.2
see https://developer.android.com/studio/releases/gradle-plugin#compatibility
Related
I currently know that kotlinc hello.kt -include-runtime -d hello.jar compiles my hello world program written in kotlin. Furthermore I am able to execute my program via java -jar hello.jar.
Setting up a Kotlin "Hello world!" console application example in IntelliJ I may choose between different Build Systems (Maven, Gradle, IntelliJ).
I would like to know what happens in the background using the IntelliJ Build System for example?
It seems that there is an ant script running considering the Build Output:
Executing pre-compile tasks…
Loading Ant configuration...
Running Ant tasks...
Running 'before' tasks
Checking sources
Kotlin: connecting to daemon
Kotlin: compiling [firstKotlinApp]
Kotlin: kotlinc-jvm 1.6.10-release-923 (JRE 17.0.1+12-39)
Kotlin: performing incremental compilation analysis
Checking dependencies… [firstKotlinApp]
Dependency analysis found 0 affected files
Updating dependency information… [firstKotlinApp]
Running 'after' tasks
Finished, saving caches…
Executing post-compile tasks…
Loading Ant configuration...
Running Ant tasks...
Synchronizing output directories…
04.01.22, 07:59 - Build completed successfully in 6 sec, 686 ms
Can someone help me out and direct me to the right place to look?
I already tried to find information with several search engines.
How to debug KSP using Idea and Gradle?
Running build task from IDE in debug mode does not attach IDE to the process.
Is there any command-line way to make the processor wait until IDE attach to thte process?
(I'm using KSP 1.5.31-1.0.0)
./gradlew :sample:build --no-daemon -Dorg.gradle.debug=true -Dkotlin.compiler.execution.strategy=in-process
If debugging without daemon is too slow (it has to start jvm everytime), ./gradlew -Dkotlin.daemon.jvm.options="-Xdebug,-Xrunjdwp:transport=dt_socket\,address=8765\,server=y\,suspend=n" ... and attach to the KotlinCompileDaemon process in the debugger.
More info here: https://github.com/google/ksp/issues/31
I have two projects on GitHub (https://github.com/NlaakStudios) (gowaf and ezgo). Debugging and Testing with VSCode and Delve work perfectly with the gowaf repo using the default launch.json. It does not work with ezgo which is just the config from gowaf moved into a different repo.
With gowaf I get the "Run Packed test" and "Run file Test" options above the package and test functions. With ezgo I do not. gowaf was created and was being debugged and tested pre-last VSCode update and ezgo after update.
Both are frameworks with no main package, so I need test enabled for non-main binaries (as I have been doing). Below is the output from the config package in gowaf (working) and ezgo (not working)
gowaf/config/
Running tool: D:\Go\bin\go.exe test
-coverprofile=C:\Users\Nlaak\AppData\Local\Temp\go-code-cover -timeout 30s
PASS coverage: 91.8% of statements ok
/d/GO_Projects/src/github.com/NlaakStudios/gowaf/config 0.059s
Success: Tests passed.
ezgo/config/
API server listening at: 127.0.0.1:27828 not an executable file could
not remove
d:\GO_Projects\src\github.com\NlaakStudios\ezgo\config\debug.test:
remove
d:\GO_Projects\src\github.com\NlaakStudios\ezgo\config\debug.test: The
system cannot find the file specified. Process exiting with code: 1
My current focus is on code coverage and this is just killing me. Complete stop and I cannot figure it out for the life of me. Any help would be appreciated. I have TeamViewer if you want to actually get your hands dirty with it as i monitor.
Thanks in advance...
Environment Information & Versions
------------------------------------------------------------
Windows 10 Home (all updates)
------------------------------------------------------------
Delve Debugger
Version: 1.0.0
Build: $Id: c98a142125d0b17bb11ec0513bde346229b5f533 $
------------------------------------------------------------
go version go1.10.3 windows/amd64
------------------------------------------------------------
VSCode Version Info
Version: 1.25.0
Commit: 0f080e5267e829de46638128001aeb7ca2d6d50e
Date: 2018-07-05T13:11:58.697Z
Electron: 1.7.12
Chrome: 58.0.3029.110
Node.js: 7.9.0
V8: 5.8.283.38
Architecture: x64
I wanted to de-compile forge src, but when I typed in the command, it gave me an error. What does it mean and how can I fix it?
Last login: Sat Feb 6 20:59:20 on ttys000
Quangs-MacBook-Pro:~ quangnguyen200415$ bash /Users/quangnguyen200415/code/nullum\ et\ vacuum/gradlew setupDecompWorkspace
Exception in thread "main" java.lang.RuntimeException: Could not locate the Gradle launcher JAR in Gradle distribution '/Users/quangnguyen200415/.gradle/wrapper/dists/gradle-2.0-bin/5h57m9vra0mjv9qs45oqtsb5c0/gradle-2.0'.
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:39)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:56)
Quangs-MacBook-Pro:~ quangnguyen200415$
I am running latest version of java 8
EDIT: tried simplifying it, no effect
Quangs-MacBook-Pro:nullum et vacuum quangnguyen200415$ ./gradlew setupDecompWorkspace
Exception in thread "main" java.lang.RuntimeException: Could not locate the Gradle launcher JAR in Gradle distribution '/Users/quangnguyen200415/.gradle/wrapper/dists/gradle-2.0-bin/5h57m9vra0mjv9qs45oqtsb5c0/gradle-2.0'.
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:39)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:56)
Quangs-MacBook-Pro:nullum et vacuum quangnguyen200415$
It's likely you've installed something that has either modified your JDK installation, or has messed with your 'JAVA_OPTS' env var. Are you running code from eclipse? it could be a change in Eclipse that is causing Gradle to be run with a different environment. Do you get the same error when running Gradle directly?
bash /Users/quangnguyen200415/code/nullum\ et\ vacuum/gradlew setupDecompWorkspace
uhm... whats up with the preceding commands...
Just do ./gradlew setupDecompWorkspace
I'm pretty sure one of those commands you've added messes up the gradle path finding.
Execute gradlew without the fancy own commands, then add your own commands till it breaks. then you know what breaks.
I'm successfully generating 2 .exec files by Jacoco within "build/jacoco" folder after running a Gradle based build and integration tests.
Gradle command:
"gradle clean build integrationTest"
Once done, it generates the following .exec files under build/jacoco folder.
test.exec
integrationTest.exec
Following is my sonar-project.properties file. When, I run "sonar-runner" from Linux prompt it completes but on SonarQube dashboard for this project, I see Unit test says some 34.5% but integration tests says 0.0%. Both .exec files have valid size. I also did "cat" on the .exec files and piped the output to "strings" command in Linux and saw that integrationTest.exec did hit the Tests functions - I have only 1 .java file.
When I run "gradle clean build integrationTest sonarRunner -Dxxx.xxx=yyy -Dyyy.xx=zzz" i.e. by passing all the sonar variable as mentioned in the sonar-project.properties file using -D option, it works but same result on SonarQube project's dashboard. Project's sonar dashboard has both widgets configured for Unit / Integration Tests and I'm including IT tests for showing Overall coverage. Overall coverage is showing 34.5% (which is Unit test % value). Sonar does see test.exec, integrationTest.exec and also auto generates overall-xxx.exec file as well during this operation.
NOTE: I'm no where - while starting tomcat on a separate putty / linux console -OR within Gradle build script, providing any value or setting JAVA Agent for Jacoco. I'm getting integrationTest.exec file and test.exec file already so not sure if JVM needs to be stopped once IT tests are complete running. I don't think I need those as i have valid file size for .exec files.
My ?:
- Why sonar is not getting IT coverage on the dashboard even though I'm setting / passing the following variable correctly:
sonar.jacoco.itReportPath=build/jacoco/integrationTest.exec
-bash-3.2$ cat sonar-project.properties
# Root project information
sonar.projectKey=com:company:product:ProjectA
sonar.projectName=ProjectA
sonar.projectVersion=1.0
# optional description
sonar.projectDescription=ProjectA Service
#Tells SonarQube that the code coverage tool by unit tests is JaCoCo
sonar.java.coveragePlugin=jacoco
#Tells SonarQube to reuse existing reports for unit tests execution and coverage reports
sonar.dynamicAnalysis=reuseReports
# Some properties that will be inherited by the modules
sonar.sources=src/java,test/java,src/java-test
# Sonar Unit Test Report path
sonar.jacoco.reportPath=build/jacoco/test.exec
# Sonar Integration Test Report Path
sonar.jacoco.itReportPath=build/jacoco/integrationTest.exec
sonar.junit.reportsPath=build/UT/results
# Sonar Binaries
sonar.binaries=build/classes/main
Narrowing down the cause: I think it's due to the .exec file for Integration test. To proove it: I passed UT exex file to both reportsPaths in Sonar variables i.e. the following and SonarQube picked both UT/IT test coverage. This prooves that if .exec file for IT tests is good (which I think it's But I need to double check) then Sonar will pick the .exec file and show a valid coverage % instead of 0.0%. Note: the following is just to proove if Sonar is picking the values or not. itReportPath variable should use the .exe file which is generated by Integration tests by Jacoco.
sonar.jacoco.reportPath=build/jacoco/test.exec
# Sonar Integration Test Report Path
#sonar.jacoco.itReportPath=build/jacoco/testintegrationTest.exec
sonar.jacoco.itReportPath=build/jacoco/test.exec
OK Found the issue. I was running integrationTest task in Gradle and was NOT attaching the jacocoagent.jar (as per Jacoco documentation) to the target JVM (Tomcat's instance) scope. Once I did that, I removed jacoco { ... } section from integrationTest task in Gradle (build.gradle or GRADLE_HOME/init.d/some.common.gradle file as this attach jacoco agent to the Java JVM in which Gradle is running). Now, once jacocoagent.jar was attached to Tomcat's JVM (as per the line below which I added in Tomcat's startup.sh script and added the variable to the command which starts Tomcat), then I ran Gradle (integrationTest) task for running IT tests.
PROJ_EXTRA_JVM_OPTS=-javaagent:tomcat/jacocoagent.jar=destfile=build/jacoco/IT/jacocoIT.exec,append=false
Then while Gradle was in progress, tests ran and I got a file (jacocoIT.exec at the given location) with some file size BUT this is not yet the final one. I had to stop the Tomcat session/JVM instance by running Tomcat's stop.sh script. Once Tomcat was stopped, I saw jacocoIT.exec file size increased significantly and this was the valid final jacocoIT.exec file (which I needed for sonarRunner Gradle task OR sonar-runner exectuable to pick and successfully push IT code coverage data to project's sonar dashboard). Once done, I got both UT + IT and it's combined code coverage.
sonar.jacoco.reportPath=build/jacoco/UT/jacocoUT.exec
sonar.jacoco.itReportPath=build/jacoco/IT/jacocoIT.exec