5

I am trying to debug maven with: jdb -attach 8000, after using mvnDebug.
I try to put breakpoints, but get:

main[1] stop in DeployMojo.DeployMojo Deferring breakpoint DeployMojo.DeployMojo. It will be set after the class is loaded. main[1] stop at Dependency:66 Deferring breakpoint Dependency:66. It will be set after the class is loaded.

When I run, the breakpoints are not called. I have the sources (generated with a maven command), but how can I make them available to the debugger?
Is there a class loader where I could put a breakpoint?

Improve this question

3 Answers 3

Reset to default
14

This may happen because your class names are wrong or because you omitted the package. If class Dependency is in package com.my.package, then break in class com.my.package.Dependency and not in Dependency.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

It works. Now, I have a stack, but list gives: Source file not found: MojoExecutor.java. How can I make the sources available to the debugger? Sorry: use... Thanks!
Apart that: main[35] use /home/emagiro/tmp/maven/maven-core/src/main/java/org/apache/maven/lifecycle/internal main[35] list Source file not found: MojoExecutor.java
try using -sourcepath <dir1:dir2:...>
Thanks... that's a command line option. There is a use/sourcepath command inside jdb, which I cannot get to work. Still trying.
0

I was using jdb -attach -sourcepath ~/path/to/project/main/java. Turns out jdb doesn't like the ~ and needs jdb -attach -sourcepath $HOME/path/to/project/main/java or the absolute path.

Improve this answer

Comments

0

For me tibtof's answer was only half what I needed ot make it work. After I explicitly added the package name, jdb would yield "Try compiling with debugging on" on this gradle project of mine:

> Unable to set deferred breakpoint package.ClassName:LineNumber : No linenumber information for package.ClassName. Try compiling with debugging on.

In this case, if you are using gradle you need to make sure that options.debug=true in the compileJava task, which you can check with the println below.

In my case I was compiling with debugging on - or so I thought. I had my build.gradle like so (based on this answer and this article):

tasks.withType(JavaCompile) { options.compilerArgs << '-Xlint:all' << '-Werror' << '-g' options.debug = project.hasProperty('debug') options.debugOptions.debugLevel = 'source,lines,vars' options.debugOptions.debugLevel = 'source,lines,vars' doLast { println "Args for for $name are $options.allCompilerArgs" println "debug=$options.debug" } }

When I ran ./gradlew build -Pdebug it printed as expected:

Args for for compileJava are [-Xlint:all, -Werror, -g] debug=true

It turns out that when I later run ./gradlew runMyTask --debug-jvm it re-ran the compileJava task because I did not pass -Pdebug again. Running gradle with --info confirms it:

Task ':compileJava' is not up-to-date because: Value of input property 'options.debug' has changed for task ':compileJava'

This fact only became apparent after a few hours when I added the aforementioned println:

afarah@gentoopc $ ./gradlew runMyTask --debug-jvm > Task :compileJava Args for for compileJava are [-Xlint:all, -Werror, -g] debug=false > Task :runMyTask Listening for transport dt_socket at address: 5005

So the solution was to run ./gradlew runMyTask --debug-jvm -Pdebug, i.e. pass -Pdebug again:

afarah@gentoopc $ ./gradlew runMyTask --debug-jvm -Pdebug > Task :compileJava Args for for compileJava are [-Xlint:all, -Werror, -g] debug=true > Task :runMyTask Listening for transport dt_socket at address: 5005

Notice debug=true now, and finally jdb did not complain and stopped at my LineNumber breakpoint.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.