Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return outline/documentSymbols even for .java files that are not in a Java project #2809

Closed
mickaelistria opened this issue Aug 23, 2023 · 3 comments · Fixed by #2823
Closed

Comments

@mickaelistria
Copy link
Contributor

In eclipseide-jdtls, we open .java files which are not in a Java project. We've disabled JDT-LS capability to place .java files in as linked resources in a "virtual" project as it causes confusion with regular usage of the IDE.
Legacy JDT UI is able to provide documentSymbols/quick outline for those files, even without a Java nature nor anything. I supect it can do that only by parsing the file and not trying to resolve anything beyond getting an unbound AST.
Unfortunately JDT-LS doesn't provide that and in case I request quick outline on a "detached" .java file, I get nothing.

It would be convenient if JDT-LS could return the outline symbols for any .java file regardless of its parent project.

@rgrunber
Copy link
Contributor

So a subset of language support that invisible projects provide without the invisible project part. I'm sure it would be possible to create some project type that could handle this. Or if all we care about is document symbols, it's probably easier just to hardcode the logic just for that method.

My only worry would be, what happens when users ask for more support (src/out/lib config, jvm config) ? Is there any way to change our virtual/invisible project solution so that it would actually work in Eclipse ?

@mickaelistria
Copy link
Contributor Author

So a subset of language support that invisible projects provide without the invisible project part. I'm sure it would be possible to create some project type that could handle this

Not really, or even not at all ;) I don't advocate for more project type, more invisible stuff. It's only that JDT can provide document symbols (list declared fields) for any Java file without the need for a project, and I would like JDT-LS to be capable of achieving the same.

Or if all we care about is document symbols, it's probably easier just to hardcode the logic just for that method.

It's so far the only case that I'm aware where JDT can do something useful without a project. So yes, it can be just the documentSymbol implementation that can be changed to not require a project.

mickaelistria added a commit to mickaelistria/eclipse.jdt.ls that referenced this issue Aug 29, 2023
The makes that the documentSymbols (and probably some other requests)
capable of processing files that are not imported in any way in the
workspace.
It consists of mainly
* Adding capability to create an ICompilationUnit for those files
* Adding extra-logic to resolve an URI for ICompilationUnit that are not
backed by an IFile.

Fixes eclipse-jdtls#2809
@mickaelistria
Copy link
Contributor Author

Actually, I think it would also be possible to provide hover (rendered javadoc for declared elements) without having the project. And if JDT-LS has it (which is most likely doable), then it would be 1 small feature JDT-UI would miss compared to JDT-LS.

snjeza pushed a commit that referenced this issue Sep 26, 2023
The makes that the documentSymbols (and probably some other requests)
capable of processing files that are not imported in any way in the
workspace.
It consists of mainly
* Adding capability to create an ICompilationUnit for those files
* Adding extra-logic to resolve an URI for ICompilationUnit that are not
backed by an IFile.

Fixes #2809
@rgrunber rgrunber added this to the End September 2023 milestone Sep 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants