lsp-java
lsp-java copied to clipboard
How do i get the LSP to pick up protobuf generated classes
when i generate classes via protobuf i get warnings all over my code with {ClassName} cannot be resolved to a type and there is no code completion. gradle seems fine finding them to compile. is there anything i have to include or a hint i can give the lsp to pick these files up?
this: https://github.com/emacs-lsp/lsp-java/issues/71
I think that you can manually alter .classpath to do that too.
this: #71
I think that you can manually alter
.classpathto do that too.
I dont think that you can manually edit the .classpath file. whenever i put a
<classpathentry> line in mine it gets nuked whenever the server starts/restarts. i would rather avoid installing eclipse to manage the .classpath file
I have luck with the hint of https://github.com/emacs-lsp/lsp-java/issues/270#issuecomment-689095922
dealing with a project that has generated classes sources to folder target/generated-sources/java
I add the following config in .classpath file in project root
<classpathentry kind="src" output="target/classes" path="target/generated-sources/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
after execute lsp-restart-workspace, the auto-completion works.
if the file already opened in buffer and auto-completion not working, I found that revert-buffer helps.
@kingsuntw i have this weird issue where whenever i modify a .project or .classpath file restarting the lsp workspace rewrites the file. Any ideas?
@kstatz12 Could you try solution from here?
Was this ever resolved? I've been struggling with this for a while now. I have a multi-module maven project with generated sources. I already built everything from the command line. I can see the artifacts in the m2 repo. But lsp-java does not see them. I'm not sure if it's building everything, but the errors all seem to be due to symbols from generated sources.
The .classpath files appear to have been automatically generated. Is there something else I need to do to tell it where to look?
I discovered that I can manually edit the .classpath in the project that can't resolve the missing types like so:
<classpathentry kind="src" path="../../../project_that_generates_types" />
As soon as I save, the number of errors drops. However, then some process immediately overwrites .classpath. I don't have the option of modifying the pom files as suggested in the solution linked above. Another problem is that there are a lot of projects. I would have to go through every one, though I would do it if I could solve the first problem.
I can confirm that at least the solution linked to by rrudakov does work. One thing I noticed, though, is sometimes projects that depend on generated files report errors, but as soon as you open the file with errors, the errors immediately go away. The behavior does not seem to be very consistent. I'm still trying to figure out how to add a certificate through vmargs. Maybe the strange behavior will resolve once the rest of the errors have been dealt with.
Once I worked through the remaining issues, the funny behavior has disappeared.
"goldfita" @.***> writes:
Was this ever resolved? I've been struggling with this for a while now. I have a multi-module maven project with generated sources. I already built everything from the command line. I can see the artifacts in the m2 repo. But lsp-java does not see them. I'm not sure if it's building everything, but the errors all seem to be due to symbols from generated sources.
The .classpath files appear to have been automatically generated. Is there something else I need to do to tell it where to look?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.
I was able to set it up with build-helper-maven-plugin. I had to add this plugin to pom.xml of the module which generates sources (in my case it was jooq library). I don't work with java now, so unfortunately I cannot provide more details.
After the senior developer updated jaxb and made a few other changes to the pom, the problem went away.