You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@atm1020 Did you find a way? Only issue I had was the resolving tests asynchronously. Neo test seem to use treesitter and stuff to find the tests but what we want is LSP call to get them. I couldn't find a way to do that. Overthought author said it can handle async, I did not find anything related to async callback or coroutine in the source code.
@s1n7ax I think I made some progress, but I skipped using the LSP method to check if the file is a test file. Neotest heavily relies on the is_test_file method, when I used lsp for this, it made everything really slow (i mean project scan etc). So, I tried to set up the other stuff. (however, when I tried, the folder filter method didn't work well, so lot of wrong files were sent to to the server)
project repo. It's depends on the nvim-java-test and nvim-java-core project, I added a separate logger to it for better debugging.
Currently, I'm not sure if it's fully async, and I don’t really know the proper way to check it, so I hope you can help with this too.
working features:
run/debug : folder/class/method.
limitation:
With the new neotest version, the project is duplicated in the tree view (fully scanned two times). I think its related to this - pr, but I haven't looked into it yet. (this pr enables the watch feature)
For the treesitter query i used the neotes-java project
This is good enough for a initial release. I will include this project in the future.
@s1n7ax It has one bigger issue, for some reason, the full project scan runs twice. This is why the project is duplicated in the tree view. I think I need some time to fix it.
The project can be used with the current nvim-java test running feature, so I think it won't cause big issues/headache for the users.(may be it can be released as a preview/optional feature )
Do you have any advice or suggestions for the project?
The way they scan the file tree is not suitable for java but there is no any other option I guess. Instead of using the hard coded java test package names I would call findTestPackagesAndTypes LS call to get the information. Then de structure the path filter out the paths passed by neotest.
@atm1020 If you could also check why the hell STDOUT is not captured by the output, that would be awesome. For some stupid reason System.out.println(">>") in tests does not output any within tests.
Thanks for the suggestions!
I would make it independent from the nvim-java-test project too. I think theres room to improve the test parser functions or to create better integration for Neotest. @s1n7ax What do you think ?
@s1n7ax Based on your suggestions I changed the is_test_file and filter_dir functions; now they are based on the jdtls responses.
I think the vscode.java.test.findJavaProjects and vscode.java.test.findTestPackagesAndTypes requests return all the information needed for the is_test_file and filter_dir functions, because these functions called heavily, caching the response of the vscode.java.test.findTestPackagesAndTypes request might be a better option (but this one lsp call still froze my editor a little bit..).
So I think the vscode.java.test.findTestPackagesAndTypes request needs to be recalled whenever a new Java file is created and during the first neotest call (or possibly after the jdtls startup instead of the first neotest call, but I'm not sure about this.)
but this one lsp call still froze my editor a little bit..
I don't understand what the hell they using nio for if it's not asynchronous?
Do you have the LSP call changes in a branch. I tried to implement that using nio library. Ran into this issue once again nvim-neotest/neotest#444
We can figure out caching later. Worst case would be using some last updated time to update the current tests.
@s1n7ax I think Ive reproduced your bug, and I found that the neotest log contains error message like this:
lazy/nvim-nio/lua/nio/tasks.lua:206: Wrapped function failed: ...cal/share/nvim/share/nvim/runtime/lua/vim/lsp/client.lua:675: E5560: nvim_get_current_buf must not be called in a lua loop callback
stack traceback:
@s1n7ax I think the issue is that the java.project.isTestFile jdtls request returns true for the ReaderData.java file. However since there are no tests in this file the vscode.java.test.findTestPackagesAndTypes command doesn't return it (the is_test_file neotest function was based on this response in the older versions.). So i didnt encounter the problem when vscode.java.test.findTestTypesAndMethods returned nil for a file during the test runs.
I plan to simply mark these kinds of files/packages as skipped.
Currently, the jdtls calls are somewhat mixed, i mean hte is_test_file and filer_dir neotest functions are based on the nio-wrapped client, while the others are not. I think i wil rewrite everything to use the nio wrapped client.
@s1n7ax I fixed the problems.
All the jdtls calls now use the nio wrapped lsp. I think this change has also resolved the "editor freeze" problem. Can you check it, please ?
Activity
atm1020 commentedon May 9, 2024
@s1n7ax Are you working on this ? I'm would like to impement this.
s1n7ax commentedon May 9, 2024
@atm1020 Give it a shot. I couldn't get it working. Check the linked discussion first.
atm1020 commentedon May 17, 2024
@s1n7ax should the implementation be in a different repository, or is it fine to include it in the nvim-java repo?
s1n7ax commentedon May 17, 2024
@atm1020 New repo would be ideal.
aeropagz commentedon May 23, 2024
would be a great feature :)!
s1n7ax commentedon Jun 25, 2024
@atm1020 Did you find a way? Only issue I had was the resolving tests asynchronously. Neo test seem to use treesitter and stuff to find the tests but what we want is LSP call to get them. I couldn't find a way to do that. Overthought author said it can handle async, I did not find anything related to async callback or coroutine in the source code.
atm1020 commentedon Jun 25, 2024
@s1n7ax I think I made some progress, but I skipped using the LSP method to check if the file is a test file. Neotest heavily relies on the
is_test_filemethod, when I used lsp for this, it made everything really slow (i mean project scan etc). So, I tried to set up the other stuff. (however, when I tried, the folder filter method didn't work well, so lot of wrong files were sent to to the server)project repo. It's depends on the nvim-java-test and nvim-java-core project, I added a separate logger to it for better debugging.
Currently, I'm not sure if it's fully async, and I don’t really know the proper way to check it, so I hope you can help with this too.
working features:
limitation:
For the treesitter query i used the neotes-java project
I'm curious what you think about it.
atm1020 commentedon Jul 24, 2024
@s1n7ax Did you have time to check it?
4 remaining items
atm1020 commentedon Jul 25, 2024
@s1n7ax It has one bigger issue, for some reason, the full project scan runs twice. This is why the project is duplicated in the tree view. I think I need some time to fix it.
The project can be used with the current nvim-java test running feature, so I think it won't cause big issues/headache for the users.(may be it can be released as a preview/optional feature )
Do you have any advice or suggestions for the project?
s1n7ax commentedon Jul 25, 2024
The way they scan the file tree is not suitable for java but there is no any other option I guess. Instead of using the hard coded java test package names I would call
findTestPackagesAndTypesLS call to get the information. Then de structure the path filter out the paths passed by neotest.https://github.com/nvim-java/nvim-java-core/blob/1ce1143c595c5f6357bede19e9bf4000bf7f980c/lua/java-core/ls/clients/java-test-client.lua?plain=1#L50-L55
Additionally you have following to get the tests.
https://github.com/nvim-java/nvim-java-core/blob/1ce1143c595c5f6357bede19e9bf4000bf7f980c/lua/java-core/ls/clients/java-test-client.lua?plain=1#L61-L66
I guess you can use
request_syncto get the information in respective filter functions.I would make it independent of
nvim-java-coreso other people can use it. For dependencies you can copy the files fromjava-coreto the project.s1n7ax commentedon Jul 25, 2024
@atm1020 If you could also check why the hell STDOUT is not captured by the output, that would be awesome. For some stupid reason
System.out.println(">>")in tests does not output any within tests.atm1020 commentedon Jul 26, 2024
Thanks for the suggestions!
I would make it independent from the
nvim-java-testproject too. I think theres room to improve the test parser functions or to create better integration for Neotest. @s1n7ax What do you think ?atm1020 commentedon Aug 5, 2024
@s1n7ax Based on your suggestions I changed the
is_test_fileandfilter_dir functions; now they are based on the jdtls responses.I think the
vscode.java.test.findJavaProjectsandvscode.java.test.findTestPackagesAndTypesrequests return all the information needed for theis_test_fileandfilter_dir functions, because these functions called heavily, caching the response of thevscode.java.test.findTestPackagesAndTypesrequest might be a better option (but this one lsp call still froze my editor a little bit..).So I think the
vscode.java.test.findTestPackagesAndTypesrequest needs to be recalled whenever a new Java file is created and during the first neotest call (or possibly after the jdtls startup instead of the first neotest call, but I'm not sure about this.)The stdout is captured by the dap console, the Junit log doesn't contain that. But we can get the dap console bufnum (https://github.com/atm1020/neotest-jdtls/blob/25438fe69aa2e168bd8594d6320d56404fcd10b5/lua/neotest-jdtls/neotest/impl/excute.lua#L216) and for example create a console for a simple test run or capture the output for the neotest result viewer.
s1n7ax commentedon Aug 6, 2024
I don't understand what the hell they using
niofor if it's not asynchronous?Do you have the LSP call changes in a branch. I tried to implement that using nio library. Ran into this issue once again
nvim-neotest/neotest#444
We can figure out caching later. Worst case would be using some last updated time to update the current tests.
atm1020 commentedon Aug 10, 2024
@s1n7ax I think Ive reproduced your bug, and I found that the neotest log contains error message like this:
When I use
nio.schedules()before the nio wrapped cliet client calls, it starts to work (https://github.com/atm1020/neotest-jdtls/blob/600380cd3b1667c60e5c43fa1d113a9c51189566/lua/neotest-jdtls/neotest/adapter.lua#L37).I pushed changes where the test file check is based on the
java.project.isTestFilejdtls call like in your example.s1n7ax commentedon Aug 11, 2024
@atm1020 Planning to add it this week. Can you see why this is not working in this project? Could be because junit5.
https://github.com/s1n7ax/spring-boot-assignment
atm1020 commentedon Aug 11, 2024
@s1n7ax I think the issue is that the
java.project.isTestFilejdtls request returns true for the ReaderData.java file. However since there are no tests in this file thevscode.java.test.findTestPackagesAndTypescommand doesn't return it (theis_test_fileneotest function was based on this response in the older versions.). So i didnt encounter the problem whenvscode.java.test.findTestTypesAndMethodsreturned nil for a file during the test runs.I plan to simply mark these kinds of files/packages as skipped.
Currently, the jdtls calls are somewhat mixed, i mean hte
is_test_fileandfiler_dirneotest functions are based on the nio-wrapped client, while the others are not. I think i wil rewrite everything to use the nio wrapped client.As far as i know, the current parser, only supports junit5 .
atm1020 commentedon Aug 18, 2024
@s1n7ax I fixed the problems.
All the jdtls calls now use the nio wrapped lsp. I think this change has also resolved the "editor freeze" problem. Can you check it, please ?
chetra-seng commentedon Apr 1, 2025
Hi @s1n7ax, I hope you're doing great. I'd love to see this feature with nvim-java. May I know the progress of this feature?
rcasia commentedon Jan 26, 2026
Hi @s1n7ax, what makes https://github.com/rcasia/neotest-java not suitable to be part of this project as a dependency?