4

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?

Marc
  • 45
  • 1
  • 5

3 Answers3

13

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.

tibtof
  • 7,857
  • 1
  • 32
  • 49
  • 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! – Marc Jun 06 '12 at 10:33
  • 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` – Marc Jun 06 '12 at 10:43
  • 1
    try using -sourcepath – tibtof Jun 06 '12 at 10:43
  • Thanks... that's a command line option. There is a `use/sourcepath` command inside jdb, which I cannot get to work. Still trying. – Marc Jun 06 '12 at 11:08
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.

Kevin
  • 1,195
  • 12
  • 14
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.

afarah
  • 748
  • 3
  • 19