Debug JUnit tests directly form VIM and Offline management of breakpoints#8
Debug JUnit tests directly form VIM and Offline management of breakpoints#8ghauerberg wants to merge 1 commit intoDica-Developer:masterfrom
Conversation
…ing the plugin to define and manage breakpoints when not running. 2. Added JDBDebugProcess which will directly start debug process with @test annontated unit tests
| # vim-jdb | ||
|
|
||
| This is a fork of Dica-Developer/vim-jdb so checkout the main branch as well. | ||
|
|
There was a problem hiding this comment.
This needs to be removed before I can merge.
| 8. use the command `:JDBStepOver` to execute to the next line | ||
| 9. with `:JDBCommand` you can send any JDB command to the JDB JAVA process, e.g. you want to see all locals do `:JDBCommands locals` | ||
| 10. with `:JDBContinue` you can resume the execution until the next breakpoint is hits | ||
| 11. with `:JDBDebugProcess` will (currently) pick the function name you are currently in if it is annontated with "@Test". It will then construct the the path to the class from the class name and package name in the file. |
| let s:job = '' | ||
| let s:channel = '' | ||
| let s:running = 0 | ||
| let s:org_win_id = 0 |
There was a problem hiding this comment.
please use camel case and not underscores
| exe l:linenumber | ||
| exe 'sign unplace 2' | ||
| exe 'sign place 2 line='. l:linenumber .' name=currentline file='. expand("%:p") | ||
| " only open when current buffer is not the file to open |
There was a problem hiding this comment.
if the todo is fixed please remove the comment
|
Thanks for that PR. I would like to merge all of the changes, but it seems that it fixes also other stuff unrelated to the PR. It would be nice if you could separate these changes. It would be easier for me to test and review. Thanks. |
| command! JDBBreakpointOnLine call s:breakpointOnLine(expand('%:~:.'), line('.')) | ||
| command! JDBClearBreakpointOnLine call s:clearBreakpointOnLine(expand('%:~:.'), line('.')) | ||
| command! JDBBreakpointOnLine call s:setBreakpoint() | ||
| command! JDBClearBreakpointOnLine call s:removeBreakpoint() |
There was a problem hiding this comment.
Please give me more context why you changed that.
| function! s:clearBreakpointOnLine(fileName, lineNumber) | ||
| "TODO check if we are on a java file and fail if not | ||
| let fileName = s:getClassNameFromFile(a:fileName) | ||
| "TODO store command temporary if not already connected |
There was a problem hiding this comment.
For me, both todo's are not fixed. I would like to keep them until they are fixed or decided not to be implemented.
| if s:running == 0 | ||
| call ch_sendraw(s:channel, "run\n") | ||
| let s:running = 1 | ||
| endif |
There was a problem hiding this comment.
this code should be moved to its own method to avoid the duplication.
| 8. use the command `:JDBStepOver` to execute to the next line | ||
| 9. with `:JDBCommand` you can send any JDB command to the JDB JAVA process, e.g. you want to see all locals do `:JDBCommands locals` | ||
| 10. with `:JDBContinue` you can resume the execution until the next breakpoint is hits | ||
| 11. with `:JDBDebugProcess` will (currently) pick the function name you are currently in if it is annontated with "@Test". It will then construct the the path to the class from the class name and package name in the file. |
There was a problem hiding this comment.
The command name is misleading in my opinion. I would prefer JDBDebugTest or JDBDebugMethode
|
|
||
| command! -nargs=? JDBDebugProcess call s:createDebugProcess(<f-args>) | ||
| command! -nargs=? JDBAttach call s:attach(<f-args>) | ||
| command! JDBDebugUnit call s:startUnitTest() |
There was a problem hiding this comment.
Where is startUnitTest defined?
| let s:currentfile = l:filename | ||
| exe l:linenumber | ||
| exe 'sign unplace 2' | ||
| exe 'sign place 2 line='. l:linenumber .' name=currentline file='. expand("%:p") |
There was a problem hiding this comment.
You no longer call this for the file open case. How is the sign placed in this case?
| 11. with `:JDBDebugProcess` will (currently) pick the function name you are currently in if it is annontated with "@Test". It will then construct the the path to the class from the class name and package name in the file. | ||
| finally it will start jdb like this e.g.: jdb -Dtest.single=functionmane org.junit.runner.JUnitCore yourpackage.classname | ||
| for this to work properly you need to set the env var CLASSPATH with your projects dependencies. For me I use gradle for dev so have a task named "classpath" and can do this from with in gradle before starting. | ||
| :let $CLASSPATH=system("gradle -q classpath") . ":build/classes/main:build/classes/test" |
There was a problem hiding this comment.
This will fail in a multi project gradle environment. I am wondering why if gradle is always there not starting the single test via gradle and then debug via this plugin. It could also start the gradle process before i debug mode.
| echom a:msg | ||
| let l:breakpoint = '' | ||
| if -1 < stridx(a:msg, 'Breakpoint hit:') | ||
| if -1 < stridx(a:msg, 'Breakpoint hit: "thread') |
There was a problem hiding this comment.
What is the reason for that change?
| endfor | ||
| let l:result = (l:result * 2) + a:linenumber | ||
| return l:result | ||
| return strpart(l:result, 4) |
There was a problem hiding this comment.
What is the reason for that change?
|
@ghauerberg I have taken some of your changes out of your PR and committed them slightly modified to master. To get more of your changes applied to the main branch it would be nice if you could rebase and explain the last changes in more detail. Anyways thanks for your work. It helped on improving vim-jdb. |
2 participants
Now using the internal sign system to keep track of the breakpoints defined across multiple files.
And added the ability to start a java process directly from the plugin, right now it only supports JUnit test cases as this was my need.