emacs-lsp
"org.junit cannot be resolved" in standard eclipse project
I'm trying to run lsp in a blank eclipse project without maven or gradle. However my lsp detects that "the import org.junit cannot be resolved," while in eclipse, I get no error. Is this because the lsp does not detect the .classpath correctly? Is there a way to solve this issue?
I don't think I can as I am working in a school project, but I don't think the contents are important. I think it is just structure. In my working directory, I have src for source files, test for test files, and bin for the class files. I will however post my .classpath and .project files to see if that helps:
.classpath:
<?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" output="bin/test" path="test"> <attributes> <attribute name="test" value="true"/> </attributes> </classpathentry> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-13"/> <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/5"> <attributes> <attribute name="test" value="true"/> </attributes> <accessrules> <accessrule kind="nonaccessible" pattern="org/junit/*"/> </accessrules> </classpathentry> <classpathentry kind="output" path="bin/default"/> </classpath>
.project:
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>REMOVED</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>net.sf.eclipsecs.core.CheckstyleBuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.jdt.core.javanature</nature> <nature>net.sf.eclipsecs.core.CheckstyleNature</nature> </natures> </projectDescription>
I don't think I can as I am working in a school project, but I don't think the contents are important. I think it is just structure.
Can you create a project with that structure and upload it somewhere with a FooBar.java in it?
I don't think I can as I am working in a school project, but I don't think the contents are important. I think it is just structure.
Can you create a project with that structure and upload it somewhere with a FooBar.java in it?
Here is a link.
I'd like to bump this, I'm having the same issue but with apache commons libraries, and in a gradle project with multiple sub projects. It's a proprietary codebase so I can't share the exact structure or content, but the issue seems to be the same, that libraries are not correctly being detected. Notable also is that this issue appeared some time in the last three weeks, as before that I was able to work with lsp-java just fine. Is there any particular information I can provide about my setup or configuration which would be helpful to debug this issue?
@jsuskalo this is separate issue. I am investigating this one. VScode is able to handle that project I I have to find out why we cant(probably we do not include certain bundle).
@jsuskalo for your project I will need minimal reproducer.
@yyoncho if you are mentioning me for the minimal reproducer, the project does reproduce this error. It doesn't detect the junit library in my tests.
@yimmt I don't need more information from you - the project you provided is sufficient.
Unfortunately I haven't been able to make a minimal reproduction case. I tried all the things that I thought may have been the cause in a minimal project, but was unable to reproduce the error. It consistently occurs in the main project that I work in however, which unfortunately means that I'll likely have to at least temporarily switch to IntelliJ for debugging. The only information I can really provide is that all packages which resolve outside of the Java standard library (everything from jackson to apache commons) are not able to resolve. I've validated that the dependencies can in fact be retrieved with gradle, and that gradle builds work as intended, and I've tried removing the project and reimporting (and deleting all .classpath, .settings/, and .project files), and none of the above were able to correctly resolve the issue. The strangest part of this is that I am able to successfully go to definition and find decompiled versions of several of the classes which are failing to be imported, which means that the language server does have them available on its classpath somewhere.
The strangest part of this is that I am able to successfully go to definition and find decompiled versions of several of the classes which are failing to be imported, which means that the language server does have them available on its classpath somewhere.
I have the exact same symptoms. I can type a symbol that is not imported and lsp will suggest I import it. Then immediately tell me it cannot resolve the import.
@marcbowes this is different issue - are you sure you are writing tests in the test folder?
I am yet to investigate this one, probably I will ask the jdt-ls repo for pointers because it works fine in vscode.
@yyoncho sorry if I misunderstood the issue
My story is: I ran gradle init, added a dependency off maven and then tried to instantiate it in App.java (the one generated by gradle init). Running ./gradlew build works and lsp-java was able to import the symbol. But running lsp-java-build-project fails saying it cannot resolve the import.
@marcbowes it will be helpful for us if you try the same with vscode. Also, did you restart the server? Additionally, can you verify doing M-x lsp-describe-session that you have picked the proper root.
Restart - yep, correct root - yep!
Like I said, it's super weird that it can do the auto-import and also show documentation and also go to definition.. but then building fails.
I must say I'm probably on a somewhat weird setup. Windows with WSL+Ubuntu running Emacs 26 inside that. I'm going to drag the repo over to my Mac and see if the same issue occurs there.
EDIT: Same thing on my Mac works! Must be something mysterious about my Windows setup.
~~This seems to have rectified itself at this point. I'm unsure why.~~ This is untrue, it resolved itself temporarily, until I did a clean build, at which point it broke again. I am very confused as to why this isn't functioning.
@marcbowes this is different issue - are you sure you are writing tests in the test folder?
I am yet to investigate this one, probably I will ask the jdt-ls repo for pointers because it works fine in vscode.
Has there been an update on this? I been very confused with people commenting here with something I think is unrelated to this issue.