I am sometimes running into obscure problems with Gradle. Sometimes it helps if i am reading the source files or adding println statements to figure out what i can do and what the state is.
But i would really like to just place a breakpoint and list the internal state of variables. is that possible using Android Studio or IntelliJ ?
I would also love to ctrl-click to the DSL keywords so i can get some context.
Just placing a breakpoint and clicking "debug" from the list of gradle tasks does not work, it just runs the tasks without stopping.
You can't debug Gradle files. We may someday implement this, as it would obviously be a great thing, but it's a long ways off. We're in the process of adding more intelligence about syntax highlighting and analysis of build files. Well, actually, JetBrains is adding it to IntelliJ and we're picking it up. This will get better over the coming weeks and months.
Original source
1. Create a debugger
Run -> Edit Configurations
Add New Configuration
Add Remote configuration
2. Open debug mode
$ export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
3. Start debugger
$ ./gradlew someTask -Dorg.gradle.daemon=false #!important, disable daemon mode
4. Attach debugger
Set breakpoints
Start debug
5. Disable debug mode
$ unset GRADLE_OPTS
Related
I have a gradle project, and when I put a breakpoint it is displayed as a red dot, with a tick inside, and it just works fine.
The problem is that in some classes (in the same project, not a dependency class), the red dot doesn't have a tick inside, and it doesn't tell why it wouldn't work. And it just doesn't work..:
What have I tried so far:
Gradle clean & build
Rebuild project
Restart debug
Invalidate caches and restart IntelliJ
Update IntelliJ to the latest version (2017.2.5)
Mute & Unmute breakpoints
This question is similar, but clearly not the same: Intellij IDEA: Breakpoint not being hit, and is shown greyed out
Did some searching through IntelliJ Help PDF:
Help Doc pg. 431
Their documentation Describes the checkmark as "Shown at run-time when the breakpoint is
recognized by the debugger as set on an
executable code line."
and the regular red dot as "Shown at design-time or during the debugging
session when the class with such breakpoint is
not yet loaded.
"
So it would seem that the line you're adding the breaking point to never gets executed. You can try stepping up line by line through the class to make sure the class is not getting hung up somewhere.
I made a n00b mistake on the IDE. Instead of hitting the debug button, I thought it would work the same as visual studio or eclipse in that I'd have to use the run button, yet when I hit the debug button (That looks like an actual bug) my break-point hit just fine.
I get this same issue intermittently from time to time, I always run the latest version of IDEA. The break points are shown as red but without a tick inside them. Even after I rebuild or re-run in debug they do not get a tick, and they do not "work", i.e., the code continues. I resolve by restarting IDEA, then restarting the debugger/debug run config.
The same happened with me on Mac machine. I followed these steps and all worked fine:
Stop server.
Close all intellij projects.
Open only the specific intellij project on which my application needs to run.
Start the server in debug mode.
I fixed this by manually deleting all build-related files (for some reason Rebuild did nothing) by running this command at the project's root folder. Note that it does also remove Intellij's temporary configuration files, that are usually not included in git repositories anyway. Replace MODULE with the subfolder containing the module for the project. If you are building an Android app with Android Studio the main module name is usually app.
rm -rf ./local.properties ./.gradle/ ./.idea/ ./MODULE/build/ ./MODULE/out/
Then restart Intellij with the File -> Invalidate Caches / Restart option, wait for the build and indexing to finish, and debugging should start working again.
Rebuild solved my problem.
clean & rebuild
Invalidates caches/restart if necessary
I had the same issue in my mac, tried restarting server, machine, invalidate caches and nothing helped. Then, I noticed when the server is started in debug mode, i didnt see this message:
Connected to the target VM, address: '127.0.0.1:64197', transport: 'socket' and I realized that there could be some problem with the server as such.
Solution:
Created new server using command line "./server create " and then associated this server for run configuration. Now started server in debug mode and I saw above message connected to socket port and I am able to see the tick marks on debug point.
I was also facing this issue and found that my tomcat configuration was not right.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>compile</scope>
</dependency>
The scope tag had value as "provided". Changed it to compile and it worked fine.
Android app configuration was the problem for me. I had minifyEnabled true in debug section inside buildTypes in build.gradle file. I had to change it to minifyEnabled false. This change forced me to set multiDexEnabled true as it states in this post Android gives error "Cannot fit requested classes in a single dex file"
My issue got resolved by just updating the IntelliJ in IntelliJIdea -> Check for updates..
All,
This could be a common bug in the Intellij IDEA debugger instead use the key short cuts
like F8 and F9 etc during the debug steps for [ step over and run to debug next point etc..] and don't rely on the debug console buttons provided in the ide
For some reason we experienced this when we upgraded from java 11 to 17. The fix was to use a SpringBoot configuration and not a maven configuration for run/debug.
For me it was a port problem, I don't know why but I had to go back to port 8082 which I was using for tomcat.
This worked for me:
Make a note of the Java version in the run configuration tab (for me its JDK 9 or later)
Go to File -> Settings -> Search for Java compiler -> set Project Bycode version to the same version that you see in run config.
Stop and rerun debugging.
Run config image
Here is what I did.
My code was within an anonymous class where the
debug point would not get the tick mark.
I extracted the code to a
new instance method of the main container class. Then I was able to set
debug point in the new method.
As shown in the picture above.
You can check whether the breakpoint is disabled, the disabled breakpoint button will be grayed out there.
I am frustrated by the long build time that IDEA needs before starting my application. I do use DCEVM to enjoy changing code on the fly better than plain hot-swap does, but this doesn't work if I really do need to start my applications multiple times.
IDEA is supposed to be able to have incremental compilation, but I'm not seeing it. I see no options to enable this. Start or starting a debug of the application, takes nearly half a minute. Must it take so long? In theory, IDEA has all the class files already generated, except for the source files that were just edited. IDEA ought to be able to fill in the few blanks, and get the application running almost instantly. What's the hold up, why does it insist it must re-compile every single source file again?
ps. I'm using the Eclipse compiler in IDEA, so that it tolerates some source files not being compilable. I have to do that, because it is one giant tree of java files, where I can not control every one.
Then I saw that perhaps Gradle does have incremental compilation. So I thought to re-create my project, this time with Gradle. I am having a very difficult time figuring out how it works, how it integrates, what tasks are moved from IDEA to Gradle (if any). Even creating a simple skeleton test application with Gradle in IDEA is very frustrating. There are all sorts of fuzzy bits all over the place that leaves you guessing. The tutorials on Jetbrains are almost useless. I can't find one single clear to the point that just explains it in a nutshell how it works. I see some demos that says, click here, and here, and there, but the results on my end aren't the same as what I see outlined.
For instance, Gradle complains that it can't find the junit jar. Ok, so I go into the project settings, and attempt to add the junit jar to the classpath. Under Libraries, I then see an entry to "Gradle: junit:junit:4.11". But there is a second one: "junit-4.11". Why two? Can I delete one? Why is the one so verbal, colon this colon that, etc.
So I add the junit jar files I have to both.
But then in the Gradle Projects window, where I see the hierarchical breakdown of the gradle project setup, verification->test. This is then supposed to run the test class I did manage to create.
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all dependencies for configuration ':testCompileClasspath'.
> Could not resolve junit:junit:4.11.
Required by:
xpert_client4:xpert_client4:1.0-SNAPSHOT
> No cached version of junit:junit:4.11 available for offline mode.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
"Could not resolve junit:junit:4.11".
Gradle is extremely frustrating. If all I have to have, is to start a main() in a large project, why would I go through this trouble of using this gradle system that offers things I don't need? Why is it so convoluted, fuzzy, and confusing?
Same goes for an Android project. IDEA can compile and run an Android app without Gradle just fine. Simply avoid anything gradle when setting up, and it just works.
Plus there are all the things that one has to do to speed up the supposedly slow Gradle system. There is the daemon thing. Parallelize, and apparently you can set it in two ways (why). Configure on demand. Globalize. Minimize. minSdkVersion. Offline (oh no, not that Maven thing that pulls down jar files from the internet over and over). jCenter. Profile.... it goes on and on. All those workarounds, hacks, adjustments, tweaks.
Is there anything to be gained by gradle-ifying a working IDEA project? Would I get faster build and startup times if I go through all this trouble? Can I avoid Gradle altogether, and forever (in the hopes that it doesn't somehow becomes mandatory).
I've been coding since the 80s. I've used all sorts of systems. I've build my own build systems. I'm not green here. I also hate having RTFM, if those FMs don't get to the point, and don't explain things well - as if the ones that wrote it, don't really understand it themselves - they know what buttons to press to get it going and that's it.
I find this thing one of the most frustrating things I have seen in a long time. The previous horrible build system I've tried in the past, and have avoided like the plague since, is Maven. The lack of clear thinking with these systems is astounding.
So, aside from these frustrations, what I'm after is: is it worth figuring out Gradle and applying all the workarounds and tweaks, so that I may, once I go through this grief, enjoy faster build and startup times of my application?
Or, would I be better off, avoid Gradle altogether, and instead, do something like place the startup of my application in a loop, so that every time I exit that the application that it re-runs main(). I would then use DCEVM to code on the fly while possible.
Lastly, I forgot to mention. Enabling automatic build in IDEA works really badly. A build seems to always involve re-building every single file, over and over. And setting build to automatic, all it ends up doing is it redoing this in the background over and over. There is nothing that happens in an asynchronous way, where when I finish editing a source file, and start the debug of the application, where IDEA has done any of the building in the background ahead of time, because it redoes the whole thing again after every single tiny little code change. Plus it makes the CPUs spike to near 100% constantly.
IDEA is a great IDE, but the whole compile thing is a total nightmare front to back.
Make sure to disable anti-virus protection in your Gradle caches directory and your IntelliJ project directory. For me, this reduces Java compilation time dramatically, because of all the intermediate files and JARs associated with Java builds. Excluding those same directories from Windows Search indexing can also help.
As of September, 2020, this is the list of default directory locations that should be exluded from virus scanning and Windows search indexing, published here.
Gradle cache: %USERPROFILE%\.gradle
Android Studio projects: %USERPROFILE%\AndroidStudioProjects
Android SDK: %USERPROFILE%\AppData\Local\Android\SDK
Android Studio system files: %USERPROFILE%\.AndroidStudio<version>\system
I published some instructions on my blog for doing this for Windows Defender and Windows Search Indexing, which I'll repost here for completeness:
Windows Defender - How to Exclude a Directory
Open Windows Defender Settings
Click "Virus & threat protection"
Click "Virus & threat protection settings"
Scroll down to "Exclusions" and click "Add or remove exclusions"
Click "Add an exclusion" and select "Folder" from the drop-down menu
Navigate to the directory to be excluded, or paste its path into the "Folder" text-box, and click "Select Folder"
Windows Search Indexing - How to Exclude A Directory
Open Windows Control Panel
Search for "index" and choose "Indexing Options"
Click the "Modify" button
Under the appropriate drive letter, navigate to the folder you want to exclude, and make sure it is unchecked
Double-check your work by verifying the directory shows up in the "Exclude" column of the "Summary of selected locations" table
Even I was facing the same issue and found one option in Intellij IDE, which closely solves my issue, but not fully.
Build Project Automatically and Compile in Parallel
Though it does not solve fully, but I see some performance improvement in build time, whenever I add/upgrade dependency and run the tests.
I have a spring boot application. I use IntelliJ 13.
I want to launch my application in debug mode and debug it. I'm on Windows and I'd like to use shared memory. I would like to just be able to click the debug icon, or a single maven goal, and the application launches in debug mode and the IDE attaches the debugger. This is how I am used to debugging most of my java apps.
However, mixing spring-boot and IntelliJ seems to complicate things. IntelliJ seems to want to connect to the wrong process when I push the green "debug" button and I can't find a way to change the shared memory address that the green 'debug' button's functionality is determined to connect to.
The closest I've come is to add jvmoptions to the maven goal in pom.xml, and then if I add a Remote run configuration, IntelliJ lets me specify a shared memory address that matches what I wrote in the pom. This requires multiple clicks to launch the application and then debug it. It works, in a similar way that using notepad.exe to write code also works. Hence my question.
Is there a 1-step solution using shared memory?
Variation of this question:
Debugging jsp with spring-boot and IntelliJ
However the question and answers are limited to using sockets.
The problem was that IntelliJ was using the Maven goal spring-boot:run as the launch configuration, and trying to debug this causes the debugger to attach to the wrong process.
Setting a new launch configuration of type Application and pointing it at the project's class with the main() method resolves this issue.
Thanks to the commentors for suggesting that this was the way to go about it!
A one click solution (tested on IntelliJ IDEA 14.0.1) using Sockets :
Open Run/Debug Configurations, Add a new Configuration of type Remote
On the Before Lauch panel, add a Run Maven Goal with the command line command:
spring-boot:run "-Drun.jvmArguments=-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
The suspend=n option is important to avoid the Maven Goal to be locked waiting the debugger to connect.
After that you will be able to just lauch this debug task and your app will be launched and the debugger will be attached.
I'm trying to debug code that I've built from source. It is started with the wrapper from Tanuki.
I'm debugging inside IntelliJ idea but I'm not sure that is the problem.
The debugger correctly stops at all lines where I've put a break point but never else so F8, "step over" doesn't work. Very tiresome as I have to put break points every where :)
Am I doing something wrong?
How do you build the project? If you build it with Ant or some other tool, make sure that compilation is performed with debug info enabled (debug=true for Ant javac task). Obfuscation and bytecode instrumentation during the build can also affect the possibility to debug. If you run under some non-standard JVM, it may also cause such problem.
When performing remote debug, ensure the target process is started with the correct JVM options suggested in the IntelliJ IDEA Remote debug configuration. Your wrapper configuration may pass them incorrectly.
Make sure you don't have a different jar on the classpath (other than the project) with the same classes. You could be stepping through the compiled classes and "breakpointing" in the sources.
This worked for me: http://devnet.jetbrains.com/thread/267022. Basically there's another lib in the classpath confusing the debugger. Simply find out which library it is by stepping into during the debug. Then find it on the project and delete it.
In my case, it was an auto generated file that was causing the confusion.
happened to me as well, on Eclipse (Mars).
Restart of eclipse solved it... as simple as that...
I also faced the same problem.Below trick worked for me:
Delete the settings for Intellij
Windows User :C:\Users{username}.IntelliJIdea14
This will restart the Intellij for you from the beginning.
Hi I also had the same behavior and I got it fixed by installing the latest IntelliJ after removing/rename the folders found in these locations https://intellij-support.jetbrains.com/hc/articles/206544519
I had to delet all the versions I previously installed. Just give it a try.
For the first time I encounter problem when I can't debug Java program in Intellij IDEA. Output to command line works, but breakpoint is ignored..
May be it's because I created Maven configuration to start the program.
It might be that I'm disconnected from JVM, but I have no idea how to connect to.
What can be the cause of such behaviour?
If you're talking about debugging something running in Maven with IntelliJ, you can
Run the maven build through IntelliJ and debug it like anything else, or
Run your build using mvnDebug instead of just mvn. It will wait for a debugger to connect on port 8000. You can have IntelliJ do this by creating a Run/Debug Configuration of type "Remote" that connects to localhost:8000.
If you are facing with non-triggered breakpoints, see following:
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360003676199-Can-t-debug-any-Java-or-Kotlin-application
In my case disabling android plugins solved the problem.
My solution was the following in IntelliJ. Go to:
Settings -> Build, Execution, Deployment-> Build Tools -> Maven -> Runner
Make sure to uncheck the box 'Delegate IDE build/run actions to Maven'
After that, I could debug and the breakpoints worked properly.
Remember that Maven and IDEA use separate build processes. Ironically I only managed today to get my own app built,deployed and run in browser today using:
Maven 3.0
Tomcat 7.0.5 with tomcat-maven-plugin
IDEA IU version 10
So ask if you need a hand.
Yucca
Sounds like the same bug in the Java VM, I just ran into:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295
The stated workaround was to use the -XX:+UseParallelGC on the Java VM.
It's not an IDE problem.
That solution was worked for me;
File-->Invalidate Caches-->Tick The Clear CheckBoxes --> Restart
Have a nice day.