Search code examples
eclipsespring-tool-suitespring-tools-4

Is command org.springframework.ide.eclipse.boot.validation.springbootbuilder needed by STS4-Eclipse?


I remember that one of the steps to upgrade my Eclipse workspace from STS3 to STS4 was to remove the command org.springframework.ide.eclipse.core.springbuilder from .project file, as described at https://github.com/spring-projects/sts4/wiki/STS3-Migration.

However, today I saw that one of my projects, that I did upgrade some time ago, is using the following command:

<buildCommand>
    <name>org.springframework.ide.eclipse.boot.validation.springbootbuilder</name>
    <arguments>
    </arguments>
</buildCommand>

Is it something introduced recently in STS4? Or is it still something from STS3 that should be removed? The upgrade guide above doesn't mention it.


Solution

  • Or is it still something from STS3

    Short answer: it belongs to STS 4 and should not be removed when migrating from STS 3 to STS 4.

    Longer answer:

    That particular builder runs 'validation checks' that are specific to STS 4 and are run inside of an Eclipse builder.

    However, there is currently only one validation rule defined in that builder. This rule checks for use of @ConfigurationProperties annotation and recommends to add the corresponding annotation processor to the classpath if it is not already there.

    Disabling or removing the builder will have no other ill-effects except for disabling that single validation check. So if you do not use Spring Boot @ConfigurationProperties then it will not affect you at all. Even if you do use it (now or in the future), the impact is marginal. Basically, you will have to remember to add the annotation processor dependency yourself manually but won't get a reminder in the form of warning in the editor.

    Moving forward, this builder is probably going to be phased out and removed in the future. Newer validations, such as the validation of 'SpEL' expression being implemented more recently, are now being defined in the language server rather than in the Eclipse builder. If we can re-implement the @ConfigurationProperties check in the language server, then it would make sense to get rid of the Eclipse validation builder completely as it would no longer serve a purpose.

    So to be totally clear, yes it is part of STS 4, and still doing something useful (in Eclipse), but it predates the adoption of language servers as means to implement things like validations in a way that is not Eclipse-specific.