Eclipse's Javadoc live hover is unavailable without a dependency on spring-boot-actuator

[wilkinsona]

In a project that does not depend on spring-boot-actuator, mousing over an annotation to see the javadoc live hover results in the following live hover being shown instead:

No live hover information available.

Live hover providers use various spring-boot-actuator endpoints to retrieve information. Consider adding spring-boot-actuator as a dependency to your project spring-devtools-issue

The absence of a spring-boot-actuator dependency should not prevent Eclipse's built-in live hovers from functioning. I'm using Spring Boot Language Server Feature 4.0.1.201810300740 in Eclipse 2018-09.

[martinlippert]

Yeah, absolutely agree.

The reason for that is that we provide this hover at certain positions to tell people why they are not seeing any live hover data from the running boot apps (to make them aware of the fact that there might not be any actuators on their projects classpath). In the VSCode case, this merges nicely with the hover information from the Java tooling, so that you can see both. Unfortunately this doesn't work yet for the Eclipse Java editor.

We could disable that information hover altogether, but I would vote for turning the Java hover support into something that supports multiple hover providers and merge them into a single hover popup. That way, people could still see the regular Java hover information even if we provide a real live data hover at the same position.

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

The goal here would be to implement a hover provider for your JDT integration that calls LSP4E to get our language server hovers as well as calls the regular Java hover provider from JDT - and merges the result.

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

@mlippert I have added live boot hint hover content to JDT javadoc hover by extension JavadocHover class.

It looks great with the exception that hyper links to source code for the boot part part of the hover not working since JavadocHovers don't support Eclipse IntroURL. I have submitted a path for JDT for Eclipse 4.10:
https://git.eclipse.org/r/#/c/133703/

Alternative solution is create JavadocHover compatible hyper links. Think it might be difficult to create the specific URL format that JavadocHover expects given our Jandex stuff... However, it might be possible to ask JDT to give us that URL (just like Javadoc content). I was thinking even to go further and ask JDT for data about type given the project name and type fully qualified name. The data would include:

• binding key
• JDoc link
• classpath container (JAR or source folder path)
• fields
• methods
• annotations

Each field would a JSON object, each method would be a JSON object. The classpath container would be an object as well

The purpose of this rather big data object would be to see if getting this data from the JDT server can replace our Jandex index stuff in the future. I see the data object format to evolve a bit over the next few months and once it's good enough replace the Jandex stuff.

If I could have 2-3 extra days on this i could try the above. What do you think?

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

There is sts/javadocHoverLink request message obtaining javadoc hover link from the Java language server.

I have also introduced sts/javaType message but these 2 are separate because JDT language server goes into source code to calculate proper javadoc hover link URL. Think it's best to have javadoc hover link in a separate message otherwise even to find a type some data about it would need to find and load the source code for the type which might be time taking.
Note that sts/javaType is unused at the moment, but will be useful once we start getting rid of Jandex.

The sts/javadocHoverLink works for VSCode hover links as well.

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

Also fixed navigation to anonymous inner types (in case bean type is anonymous inner class)

[martinlippert]

There is a nightly build available that already includes the fix:
http://dist.springsource.com/snapshot/STS4/nightly-distributions.html

The new hover now doesn't hide the Java details anymore, but merges the content of the Spring Tools 4 live hover information with the Java hover details, so that you can see both.