I have developed a game with LibGDX library.
I am using socket programming libraries as a module in the project.
I am planing that every process of my LibGDX game will be a client for my server.
I structured it.
But I can't run more than one game at a time to test multiplayer functionality.
When I run the game first, everything is okay, but the second time I click run anything run until the first instance is closed.
I think that's because of Gradle.
I tried to change "Build and run using IntelliJ Idea" from Gradle settings, but this time I had an exception. It cannot read my assets file.
How can I solve this problem?
enter image description here
I have solved it with a Gradle command.
./gradlew desktop:run
Same problem here. Desktop app starts but gradle build never ends and all following builds have to wait until I exit the app or stop the gradle build process.
Setting the "allow multiple instances" option in the Application run configuration did not help.
Making a gradle configuration with "desktop:run" has the same effect and "allow parallel run" did not help.
This started after the Android Studio updating to version "Arctic Fox 2020.3.1"
Starting from command line with "./gradlew desktop:run" in several terminal windows works, but is laborious.
Update with a temporary solution (until the error is fixed):
Create a JAR-Application run configuration. Build the jar in the "before launch" section with Gradle task "desktop:dist" and point to the jar in "Path to JAR".
Hints:
You can safely ignore all the "xmas" strings in the image :)
"XstartOnFirstThread" is only necessary on Mac OS.
On some recent "intellij/android studio" versions is a bug that breaks "desktop:dist" the solution is to include "duplicatesStrategy = DuplicatesStrategy.INCLUDE" in desktop/build.gradle:
task dist(type: Jar) {
manifest {
attributes 'Main-Class': project.mainClassName
}
dependsOn configurations.runtimeClasspath
duplicatesStrategy = DuplicatesStrategy.INCLUDE
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
with jar
}
Enable Allow multiple instances option in Run/Debug Configuration:
Related
I'm trying to run multiple 'gradle installdebug' commands in parallel using a java program using multiple threads. Basically, this is to compile multiple pre-written android apps together in parallel as those apps are not dependent on each other. But all other gradle commands waits with the message 'busy Daemons could not be reused' until the first command completes its execution. I need help in running all the gradle command independently at the same time. more details below.
I have 10 android app folders in windows 10 machine and my java program goes into each of this app folder and executes 'gradle installdebug' command. This happens in parallel using multiple threads. This command compiles android app into APK and install it to the running android emulator. All of the 10 commands get executed successfully and the APKs are installed as expected. The problem I'm facing is that the 9 gradle jobs are queued until the first one is finished, and then remaining 9 gradle jobs runs in parallel. I tried to run the same gradle commands with .Net c# code too, but same issue is observed. I believe this is not a multithreading issue from java code or c# code, instead it is a gradle configuration issue. Looks like I'm missing something while forming the gradle command or configuring the gradle either globally or in the android app gradle settings files.
I'm using the gradle 7.5.1 offline version that I extracted into C: drive for the gradle binary/command as the android app have no dependencies to download while compiling. At end of the question, I provided the android gradle settings files too.
This is the command that I execute from the code.
cmd.exe /c C:\gradle-7.5.1-bin\bin\gradle installdebug
Starting a Gradle Daemon (subsequent builds will be faster)
Task :preBuild UP-TO-DATE
Task :javaPreCompileDebug
Task :mergeDebugResources
and goes on....
Initially for few tasks it runs in parallel with above output then for rest of the commands the gradle outputs the following messages and waits. In this example, from the 7th command it starts queuing. But If I run the program again, only one gradle command gets the daemon, rest all gets queued. On multiple runs the busy daemons count keeps increasing even beyond 100s.
Starting a Gradle Daemon, 6 busy Daemons could not be reused, use --status for details
[ My Note: here it waits for the first gradle command to finish, then this continues. same for the rest of the 8 commands ]
Task :preBuild UP-TO-DATE
Task :javaPreCompileDebug
Task :mergeDebugResources
and goes on....
I tried the command with --no-daemon as shown below.
cmd.exe /c C:\gradle-7.5.1-bin\bin\gradle --offline --no-daemon --build-cache installdebug
With this command I don't see the 'busy Daemons could not be reused' message, but it is slow as for each command a single Daemon started and stopped as shown in below output. Also, this is still having the same problem of waiting for the first command to be complete before running other commands for other android apps.
To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.5.1/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build
[ My Note: here it waits for the first gradle command to finish, then this continues. same for the rest of the 8 commands ]
> Task :preBuild UP-TO-DATE
> Task :javaPreCompileDebug
and goes on....
I have no idea why the other 9 gradle commands are waiting until the first one finished as there is no dependency between them because each of these commands are executed in separate android app folders.
To provide more info, the following is the "build.gradle" file the each of those 10 android apps has.
plugins {
id 'com.android.application'
}
android {
namespace "com.example.simple.myapp1"
compileSdk 31
defaultConfig {
applicationId "com.example.simple.myapp1"
minSdk 30
targetSdk 31
versionCode 1
versionName "1.0"
}
signingConfigs {
aerndappsigning {
keyAlias 'androiddebugkey'
keyPassword 'android'
storeFile file('platform.jks')
storePassword 'android'
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
debug {
signingConfig signingConfigs.aerndappsigning
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
dependencies {
}
the following is the "gradle.properties" file in the android app.
org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8
android.useAndroidX=true
android.enableJetifier=true
android.nonTransitiveRClass=true
org.gradle.daemon=true
org.gradle.parallel=true
the following is the "local.properties" file in the android app.
sdk.dir=D\:\\AndroidSdk
finally, the following is the "settings.gradle" file in the android app.
pluginManagement {
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
plugins {
id 'com.android.application' version '7.1.0-alpha11'
id 'com.android.library' version '7.1.0-alpha11'
}
}
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = "myapp1"
include ':app'
Before posting this question, I searched solutions online, landed up on many posts having similar output, but nothing helped as none of those use cases is similar to what I explained above like running the command in parallel in multiple threads.
The other suggested solutions I tried and their outcomes is as follows:
gradle --stop -> this stops the running gradle daemons but does not completely remove them, ending up with same 'could not reuse' problem.
C:\Users\<myuserdir>\.gradle\daemon\7.5.1 -> removing this directory removes all the stopped daemons completely, but this again ended up being slow as daemons are started again. On the next run we again started seeing the 'busy daemons' error.
org.gradle.daemon=true; org.gradle.parallel=true -> added these 2 lines to 'gradle.properties' files. no difference in output.
Please note that this 'gradle installdebug' is executed within different android app folders that are meant for different android apps. I'm not referring to the gradle configurations of sub-projects inside single android app. I'm also not referring to the parallel gradle tasks within a single android app.
I would highly appreciate if you can provide any input to resolve this issue as I have very limited knowledge in the gradle configuration. In a nutshell, I'm looking for a gradle configuration or parameters where all of the 'gradle installdebug' commands can run independently when executed from multiple threads. Is it possible to start 'n' number (say 10) of gradle daemons and keep it running and use it to serve 'n' commands in parallel and never stop until explicitly stopped?
Everytime I check out and open a project in Intellij I need to change the gradle plugin setting "Use Gradle from" from the default "'gradle-wrapper.properties' file" to "'wrapper' task in Gradle build script"
Is there a way in Intellij 2020 to make the shown option the default?
Reason I am asking: Generated gradle-wrapper files are not in our VCS, but the build.gradle is, and it has the wrapper task configured with the desired version. So when I check out a project, Intellij does not find gradle.properties (and neither can download gradle from web, as that is blocked). I then have to change the option "Use Gradle From" manually each time.
Another solution I tried is to automatically run a script when opening a module, which would run gradle wrapper with a fixed gradle version for the module, hence generating the missing wrapper files. But I find no possibility in Intellij to trigger that upon import..
It is not possible to change this setting for all projects. Please vote for this request: IDEA-215792.
I have a plugin where I need to toggle a property base on whether a task is going to run or not. This is needed because when running in ide (intellij) this flag needs to be disabled whereas if the specific runtime task is run this flag needs to be enabled.
I've tried
gradle.taskGraph.whenReady { if (it.hasTask(tasks.runtime)) {
javafx.configuration = "compileOnly"
}
}
but this gives me a error
Cannot change dependencies of dependency configuration ':implementation' after it has been included in dependency resolution.
Is there any way to set this property earlier (during plugin configuration) based on tasks or a better way to complete this?
In build script you can evaluate following properties which IDE adds:
idea.active property that IDE sets when you run Gradle tasks from IDE;
idea.sync.active property which is added by IDE when IDE reloads project from Gradle build scripts.
For example: System.getProperty('idea.active').
My IntelliJ Idea projects have been working fine until I cloned a new project from our repo and installed Gradle.
This new project runs, but running the debugger causes the following error:
I've completed the steps recommended in this similar SO question. I have also read the Gradle Daemon guide.
Some helpful information:
-Gradle does respond to command line prompts, including --profile and --status:
-The project builds and executes; the problem is only the debugger. Is this a mapping issue between IntelliJ and Gradle?
-In the Settings menu, Gradle JVM: is set to "Use Project JDK (Java version "1.8.0_211") and this program is written in Java 8. Delegate settings set to: Build and run using intelliJ IDEA. Run tests using IntelliJ IDEA. Should these change to Gradle?
-I took the advice of one of the respondents and had one of our IT guys check out my ports and firewall settings. He was unable to solve the problem and said the issue is with Gradle.
So far, nothing has worked. What should I do?
I solved this problem after some tinkering:
In (IntelliJ) File > Settings > Build, Execution, Deployment > Gradle, I changed "Use gradle 'wrapper' task configuration" to "Use local gradle distribution."
Also, notice in this screenshot that "Gradle VM options" has a custom value; this was suggested as a solution in another post. This relates to memory management, as some people speculated that the daemon was crashing because of a RAM issue. My solution appears to work regardless of whether I alter that value.
Is there a tool that will allow me to set breakpoints in a build.gradle file and step through tasks in a debugger?
Note: I believe that I'm asking a different question than similar stackoverflow questions about debugging Gradle plugins, where (presumably) the intent is to step through custom Groovy or Java plugin code located in a separate file. I want to set a breakpoint in a Gradle task in a simple build.gradle file, like...
task example {
println "I want to set a breakpoint here"
}
...so that when I run gradle example I can inspect the context in a debugger.
(For those who would point me to IntelliJ...although JetBrains' website advertises that they support debugging Gradle scripts in IDEA UI, AFAICT this is untrue, as this was reported broken in IDEA13 EAP and hasn't been fixed in IDEA14. See Debugging Gradle build files in Intellij / Android Studio )
Is there any debugging tool that allows me to set a breakpoint in a build.gradle file, or is there something about the Gradle DSL that makes it fundamentally impossible to set breakpoints in a task such as my example, above?
There is the easier way:
just add in your command line -Dorg.gradle.debug=true --no-daemon
For example:
gradle nameOfTask -Dorg.gradle.debug=true --no-daemon
Then you should start your IDE and run remote debugging with localhost port 5005, that all.
Gradle is waiting to you, because standard option server=y
org.gradle.debug
When set to true, Gradle will run the build with remote debugging enabled, listening on port 5005. Note that this is the equivalent of adding -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 to the JVM command line and will suspend the virtual machine until a debugger is attached.
Link to docs
IntelliJ 2018.2 added the ability to debug Gradle scripts in a similar fashion to how you might run/debug other projects. You can see the announcement in the release notes here.
Here is a screenshot of some of the documentation from 2018.2:
It does not yet support the kotlin-dsl (see gradle/kotlin-dsl/issues/39).
Personnaly I do this when I need to debug build scripts:
Inside you terminal do
export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
Then run your build
gradle clean install
Finally put some breakpoints and launch the remote debug configuration inside your IDE on the port 5005 and you’re good to go!
export GRADLE_OPTS does not work for me.
Try this:
1 Add remote debug config
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
2 add breakpoint in gradle
3 ./gradlew your task --stacktrace -Dorg.gradle.daemon=false -Dorg.gradle.debug=true
4 Attach debug in studio
click icon
Then the breakpoint stops !!
If console is not goiong, click this in debug pannel in studio.
After reading various answers here the following steps will help you debug build.gradle to being able to break and investigate variables inside any custom task. I am using Eclipse remote debugging facilities
Place this simple code where you want to break: try {throw new RuntimeException('Break');} catch (RuntimeException e) {}
As recommended start your task with gradle mytask -Dorg.gradle.debug=true --no-daemon in the command prompt (don't have to do it in Eclipse)
In Eclipse do Run -> Add Java Exception Breakpoint, choose RuntimeException and click "OK"
Again in Eclipse go to Run -> Debug Configurations -> Remote Java Application and create new configuration that listens on localhost:5005. Name it whatever you want. Select a project that contains build.gradle you are debugging. Click Apply and Debug
At this point the execution will start but will pause at the Exception-throwing line. And you can then start looking at your variables in the `Debug -> Variables" view, inspect the stacktrace, step through the code etc.
No magic, alas, you will not see anything highlighted in build.gradle but you can pretty much guess where you are at
Obviously on subsequent runs you don't need step 3 and in 4 you can reuse previously created configuration
If you want to use this in the multiple places simply create a method, use different type of exception and feel free to enhance this idea in any way possible
For example:
void halt() {
try {
throw new RuntimeException('Break');
} catch (RuntimeException e) {
print('Paused')
}
}
task iterateDeclaredDependencies {
doLast {
Object configs = configurations.all
halt();
print(configs)
}
}
I use
set JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8989"
then 2 gradle processes are listening :
Listening for transport dt_socket at address: 8989
Listening for transport dt_socket at address: 8989
I can connect to both of them with 2 remote debug launch configurations in Eclipse although it's the same port.