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

CTRL-click navigation does not handle properties on super class correctly #326

Closed
wilkinsona opened this issue Jul 16, 2019 · 5 comments
Closed
Milestone

Comments

@wilkinsona
Copy link
Member

I've seen two variations of this problem in two different workspaces. In one, I get numerous Unknown property errors. In the other, I don't get any errors but command-click navigation for those same properties does not work.

You should be able to reproduce the problem using STS 4.3.1.RELEASE, a fresh workspace, importing a clone of https://github.com/spring-io/start.spring.io as existing Maven projects, and ignoring the Maven lifecycle problems reported during import. If you open application.yml in start-site you should either see tens of errors, or you should see that command-click (assuming macOS) navigation doesn't work. A good way to see the latter is to scroll to the bottom of the file, hold down command, and mouse of the list of languages. You should see that only default is navigable and that name and id properties are not. The languages property itself is known to be a List<io.spring.initializr.metadata.DefaultMetadataElement>. The default property is on that class but name and id are on its superclass.

You can see a similar problem a little bit further up the file with types property. There you should see that action, tags, and description are all navigable but default, name, and id are not.

@kdvolder
Copy link
Member

kdvolder commented Jul 25, 2019

In one, I get numerous Unknown property errors.

What makes you think this is the same problem? Sounds like a different problem to me. When there are many incorrect errors, then it probably means something causing metadata to go partially missing (if it was completely missing / empty then no errors would be reported as the checking gets disabled in that case). However, this is only a guess and unless I can reproduce it, there's no way to be sure what is going on exactly or what may be causing it.

The fact that validation sometimes works correctly (i.e. you don't see false errors, but only some issues with navigation makes me beleave that handling of super properties in validation is working properly, provided the metadata is all correctly generated and detected).

In the other, ... command-click navigation for those same properties does not work.

That is easily reproducible for me. I think this is just a bug in the 'ctrl-click' handling specifically and has nothing to do with validation. I will focus on that problem for now and can try to debug the other problem if you can find a way to reproduce it.

Here are some wild guesses as to what could be the reason (for the invalid error markers):

  • JDT APT incorrectly setup (i.e. an issue in the project configuration for the @ConfigurationProcessor annotation processors).
  • Problems because the ConfigurationProcessor itself doesn't work reliably under Eclipse's incremental builds.
  • Some issue sending update events to the language server when the metadata has changed in the workspace.
  • Some issue caused by incorrect handling of metadata spanning multiple projects in the workspace (i.e. related to the fact that metadata is consumed from a project dependency, this is likely as such scenarios are not very well tested).

Assuming its one of these you could try 'fix' the issue by:

  1. Maven Update Project -> forces the reconfiguration of the annotation processor by m2e.apt
  2. Perform a 'project clean' of all projects in the worspace -> forces full build (running annotation processor on all of the code, assuming m2e.apt did it's thing correctly in step 1, this then should create 'complete' metadata.
  3. close all source and re-open, or, restart Eclipse -> this causes language server restart.

What exactly happens when you try these steps may provide a hint as to what the problem is as well.

For example if steps 1 and 2 don't yet fix the issue but step 3 does, then its likely that the data is there but the LS wasn't aware that it changed (and needed to be re-parsed).

@kdvolder
Copy link
Member

kdvolder commented Jul 25, 2019

Documenting a more easy way to reproduce the navigation issue:

  • create a new boot project with 'start.spring.io' do not add starters
  • add dependency like this to the pom:
		<dependency>
			<groupId>io.spring.initializr</groupId>
			<artifactId>initializr-generator-spring</artifactId>
			<version>0.8.0.BUILD-SNAPSHOT</version>
		</dependency>
  • add repository:
	<repositories>
		<repository>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
			<id>spring-snapshots</id>
			<name>Spring Snapshots</name>
			<url>https://repo.spring.io/libs-snapshot</url>
		</repository>
	</repositories>
  • create application.yml with this contents:
initializr:
  languages:
  - name: foo
    id: yada
    default: false

We can notice the following:

  • validations are working properly, changing any of the property names to bad spelling shows a warning.
  • CTRL-click navigation works only for 'default' but not for 'name' and 'id' (as reported by Andy).

@kdvolder kdvolder changed the title Configuration property analysis does not handle properties on super class correctly CTRL-click navigation does not handle properties on super class correctly Jul 25, 2019
@spring-projects-issues
Copy link

(comment in Pivotal Tracker added by Kris De Volder:)

Trying to verify the fix prior to delivering. Seems to work fine now in vscode but still not working in the latest STS 4 snapshot.

Investigating...

@spring-projects-issues
Copy link

spring-projects-issues commented Aug 2, 2019

(comment in Pivotal Tracker added by Kris De Volder:)

Working fine in Eclipse in my runtime workbench. I suspect something is not percolation properly in build pipeline somewhere. Strangely all builds are green however. So its a bit puzzling.

@spring-projects-issues
Copy link

(comment in Pivotal Tracker added by Kris De Volder:)

Seems I was somehow testing an old build. After downloading it again it is working.

Delivering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants