Add property 'spring-boot.version' to dependency managements

[stepio]

Dear Spring Boot team,

Thank you very much for this project - I use it much and it's really great.
I'd like to propose a minor improvement.

Use case:

1. I'd like to use this set of modules:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-log4j2</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-thymeleaf</artifactId>
        </dependency>

Although logback is nice, I found that log4j2 is a little bit better in terms of configurations' flexibility.

To prevent error with "multiple SLF4J bindings" I need to exclude "spring-boot-starter-logging" from both "spring-boot-starter-actuator" and "spring-boot-starter-thymeleaf".

The cleanest way to achieve this (correct me if I'm wrong) is to add next block to my dependency management block ("version" tag is required by maven and cannot be omitted):

            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter</artifactId>
                <version>${spring-boot.version}</version>
                <exclusions>
                    <exclusion>
                        <groupId>org.springframework.boot</groupId>
                        <artifactId>spring-boot-starter-logging</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>

So if I had "spring-boot.version" variable defined in "spring-boot-dependencies" module, that would be a little bit cleaner in terms of future support. Otherwise, I have to maintain this variable myself and update both this value and parent's version (I extend "spring-boot-starter-parent") - not a big issue, obviously, but I'd prefer to avoid this.

What do you think? Does this make sense?

[wilkinsona]

There's no need for the <version> tag if you're using Spring Boot's dependency management (either by importing the spring-boot-dependencies bom or by using spring-boot-starter-parent as your project's parent.

[stepio]

Unfortunately you're wrong. I do use Boot's dependency management, but I also define my own - for the additional dependencies. And in this case I add:

    <dependencyManagement>
        <dependencies>
            ...
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter</artifactId>
                <exclusions>
                    <exclusion>
                        <groupId>org.springframework.boot</groupId>
                        <artifactId>spring-boot-starter-logging</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            ...
        </dependencies>
    </dependencyManagement>

This allows excluding spring-boot-starter-logging from each transitive spring-boot-starter.

If I do not specify version tag, I get next error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.6:jar (default-jar) on project payments-client: Error assembling JAR: For artifact {org.springframework.boot:spring-boot-starter:null:jar}: The version cannot be empty. -> [Help 1]

Maybe there is a better way to exclude spring-boot-starter-logging effectively?

[wilkinsona]

Your original description didn't show that the dependency declarations were part of dependency management. That's quite a key detail here. Regardless, we will not be introducing a spring-boot.version property. It was removed, for good reason, in #5014. You may also be interested in #7048 and #8493 which are, essentially, duplicates of this issue.

Maybe there is a better way to exclude spring-boot-starter-logging effectively?

That's really a Maven question, rather than a Spring Boot question. As mentioned in the guidelines for contributing and guidelines for support we prefer to use GitHub issues only for bugs and enhancements.

[stepio]

I see - my exact case was discussed in scope of #5014 and current behavior was considered lesser evil.

No problem, thanks!