MissingConfigurationProcessorRule produces a false positive when developing Spring Boot

[wilkinsona]

I like to use the Spring Boot tooling in the workspace that I use for Spring Boot development. Unfortunately, this results in a couple of hundred warnings that are similar to the following:

When using @ConfigurationProperties it is recommended to add 'spring-boot-configuration-processor' to your classpath to generate configuration metadata

The problem appears to lie here: https://github.com/spring-projects/spring-ide/blob/8b57cc822e5330d1f95c7342b80b0e0a1a1fd6a9/plugins/org.springframework.ide.eclipse.boot.validation/src/org/springframework/ide/eclipse/boot/validation/rules/MissingConfigurationProcessorRule.java#L120

In my, admittedly unusual, case spring-boot-configuration-processor isn't a jar but a reference to the project. As a result, it's not found and the warning is generated.

[kdvolder]

Sounds like that would be easy enough to remedy. Thanks for reporting.

Side Note: Eclipse JDT APT doesn't support annotations processors execution in the workspace unless its in a jar dependency. So while running build from commandline will probably work as expected in your setup, the processor will not be executed in workspace builds.

Anyhoo, I guess that doesn't really change the fact that you probably don't want to see this warning.

[kdvolder]

@wilkinsona I've relaxed the validation check so it now also accepts:

classpath entry corresponding to a project called 'spring-boot-configuration-processor' (or a source folder of such a project).

I imported all of spring-boot github repo into my workpsace as 'existing maven project'.

The relaxing of the rule gets rid of a lot but not all of the warnings. When I look at the remaining warnings it looks like they indeed do not have any dependency corresponding to the spring-boot-configuration-processor. So I think the warning is legit. However, maybe I just don't fully understand how the processor would be called from these projects.

So Andy, if you could please give this a try and provide feedback on the remaining warnings that would be much appreciated. Are they indeed legit as I suspect? Or are they still false positives. If the latter, could you explain why (and perhaps a provide some suggestion on how we could detect and avoid the false positive?).

If you don't feel like installing a nightly update, we can focus on a specific example here. In my workspace there's a warning for the use of @ConfigurationProperties in here:

https://github.com/spring-projects/spring-boot/blob/fb1c7c82b4dd26714b264f0afd269c7f27c203b7/spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/jdbc/BasicDataSourceExample.java#L41

There's about 20 or so others that look similar (example or documentation snippets?).

If you did wan to give it a try you can download a nightly build from here:

http://dist.springsource.com/snapshot/STS4/nightly-distributions.html

I would recommend downloading something from the section SPRING TOOL SUITE 4 - BASED ON ECLIPSE 2018-09 RELEASE (4.9.0) (rather than mess around with update sites).

[wilkinsona]

Hi, Kris. Thanks for the updates. I've installed spring-tool-suite-4-4.1.0.CI-B1404-e4.9.0-macosx.cocoa.x86_64.dmg. When I import Boot's source, I don't see any configuration processor warnings in any of its modules. If I create an app via the Spring Starter Project wizard and add a @ConfigurationProperties class to it, I do see a warning. Applying the quick fix resolves the warning.

[kdvolder]

Great! Thanks for verifying the fix. And also for reporting it in the first place.

[wilkinsona]

No problem, although it seems to be fixed and then some. As I said, I get no warnings at all for any of Boot's own modules, not even spring-boot-docs where you were still seeing some warnings and where I'd expect to see some as the processor isn't on the classpath (it doesn't need to be as we don't care about the metadata in that case).

[kdvolder]

... not even spring-boot-docs where you were still seeing some warnings

Hmm... that is a bit odd. It might be because the project was already in your workspace and didn't get built yet (rule is checked during the workspace build). If that's the case then forcing a clean workspace build should start showing the warnings. If that doesn't happen I'm not sure how to explain it.