Remove spring-boot.version property from spring-boot-dependencies

[wilkinsona]

It, for good reason, doesn't control the version of any Spring Boot dependencies but people assume that it will. This is confusing people. Assuming it doesn't break the release process, we should get rid of it.

See #3992 and http://stackoverflow.com/questions/34961808/maven-and-spring-boot-dependencies/34961950#34961950

[snicoll]

👍

[klieber]

@wilkinsona I think there is a use case that was not considered before removing this property. I have a multi-module project using spring boot. In my parent pom I have a dependencies management section that excludes spring-boot-starter-logging from spring-boot-starter so that Log4j 2 can be used. Prior to upgrading to 1.4.0 this is what that looked like:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>1.3.3.RELEASE</version>
</parent>
<dependencyManagement>
  <dependencies>
    <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>
  </dependencies>
</dependencyManagement>

After upgrading I have to either hard code the version in the dependency management section or create my own property and hard code it there like this:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>1.4.0.RELEASE</version>
</parent>
<properties>
  <spring-boot.version>1.4.0.RELEASE</spring-boot.version>
</properties>
<dependencyManagement>
  <dependencies>
    <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>
  </dependencies>
</dependencyManagement>

So now I have two places where I have to maintain the version of spring boot and run the risk of having mismatched versions.

I understand the reason for the change is to make things less confusing but I feel like an option that just prevents someone from overriding the property or at least warns them if they do would be better.

For instance, in the spring-boot-maven-plugin there could be a goal in the initialize phase that just sets the property regardless if it was already set or not and therefore if anyone tried to set the property if would just get overwritten anyway. You could also add a warning if it is already set and the value doesn't match so that users know that setting it has no effect.

Even with this change you would still want to not reference the property in the spring-boot pom files so the changes that were made in this pull request are still relevant. Basically, what I'm suggesting is a read-only property that the plugin will make available so that it can be used when a project needs to reference the spring boot version. If this sounds good to you I'd be happy to open a pull request with this change.

[wilkinsona]

That sounds rather complicated to me, but I'll defer to @snicoll as he's the team's resident Maven expert.

[snicoll]

+1 with @wilkinsona. Either way, if you use the parent X.Y.Z you shouldn't be allowed to override X.Y.Z. I agree that your use case is a bit annoying but it's not annoying enough for us to consider reverting this, sorry.

[klieber]

@snicoll, I think I have been misunderstood. I'm not suggesting reverting the change. I'm suggesting adding a feature to the maven plugin that makes a property available. It is not a property that will be used by the spring boot build at all, just generated by the plugin so that it can be referenced.

To ease your concern @wilkinsona of complication it is really quite simple. This is similar to what the git-commit-id-plugin does when it makes all the git commit information available as maven properties (example). I have also done something similar in my phantomjs-maven-plugin where I set a property indicating the location of phantomjs.

What I haven't confirmed is if this would actually work for my use case because I'm not sure if maven runs the initialization phase before resolving the versions in the dependency management section. I would think that it does because the initialization phase is for doing things like setting properties but I would need to try it out first. I don't want to waste my time though if it's never going to see the light of day so I just need to know if this would be something the team would be OK with pursuing.

Again, not saying we should revert this change and definitely agree that a user should not be able to set this property and have that effect what version of spring boot dependencies are being pulled in. I also +1 agree with @wilkinsona on the original change.

[snicoll]

I got you the first time @klieber - I don't think we should do this, sorry.

[klieber]

Understood. Thanks.

[alan-czajkowski]

@snicoll I have yet another use-case that is quite important and requires the use of ${spring-boot.version}:

      <plugin>
        <groupId>org.liquibase</groupId>
        <artifactId>liquibase-maven-plugin</artifactId>
        <version>${liquibase.version}</version>
        <configuration>
          <verbose>true</verbose>
          <driver>${jdbc.driver}</driver>
          <url>${jdbc.url}</url>
          <username>${jdbc.username}</username>
          <password>${jdbc.password}</password>
          <outputChangeLogFile>${project.basedir}/src/main/resources/db/changelog/db.changelog-init.yaml</outputChangeLogFile>
          <referenceUrl>${jpa.url}</referenceUrl>
          <changeLogFile>${project.basedir}/src/main/resources/db/changelog/db.changelog-master.yaml</changeLogFile>
          <diffChangeLogFile>${project.basedir}/src/main/resources/db/changelog/db.changelog-diff.yaml</diffChangeLogFile>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.liquibase.ext</groupId>
            <artifactId>liquibase-hibernate5</artifactId>
            <version>${liquibase.version}</version>
          </dependency>
          <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
            <version>${spring-boot.version}</version>
          </dependency>
          <dependency>
            <groupId>javax.validation</groupId>
            <artifactId>validation-api</artifactId>
            <version>${javax-validation.version}</version>
          </dependency>
        </dependencies>
      </plugin>

where

          <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
            <version>${spring-boot.version}</version>
          </dependency>

requires the <version> explicitly defined in the dependency definition because it is a Maven plugin dependency and cannot leverage Spring Boot parent's <dependencyManagement>, because if you omit the <version> tag then it results in Maven throwing the following error on the CLI:

[ERROR]   The project ... has 1 error
[ERROR]     'build.plugins.plugin[org.liquibase:liquibase-maven-plugin].dependencies.dependency.version' for org.springframework.boot:spring-boot-starter-data-jpa:jar is missing.

and no I cannot use <version>${project.parent.version}</version> because I'm using an intermediary parent POM that sits between the Spring Boot parent POM and my project's POM

spring-boot-dependencies-2.3.3 POM had ${spring-boot.version} 👍, but
spring-boot-dependencies-2.3.4 POM had ${spring-boot.version} removed 👎 #23174 and it broke my build

please re-open this issue and keep ${spring-boot.version} in the spring-boot-dependencies POM once and for-all