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

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

Comment From: snicoll

:+1:

Comment From: 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.

Comment From: wilkinsona

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

Comment From: 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.

Comment From: 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.

Comment From: snicoll

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

Comment From: klieber

Understood. Thanks.

Comment From: 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

Comment From: snicoll

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

The issue you commented out is 4 years old. spring-boot.version was added by mistake when we moved the build to Gradle in 2.3.x and we won't add it again. Besides, I don't think liquibase should require Spring Data so the problem you're currently experiencing can be avoided.

Comment From: alan-czajkowski

FYI: marking my comment as "resolved" without actually providing any kind of solution isn't cool

for anybody stumbling here from the internet looking for a similar problem to mine, this is a potential solution that appears to work but I have not extensively tested:

...
      <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</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring-framework.version}</version>
          </dependency>
          <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-orm</artifactId>
            <version>${spring-framework.version}</version>
          </dependency>
          <dependency>
            <groupId>javax.validation</groupId>
            <artifactId>validation-api</artifactId>
            <version>${javax-validation.version}</version>
          </dependency>
        </dependencies>
      </plugin>
...

this is to get the Liquibase diff functionality working: $ mvn liquibase:diff where:

<hibernate.dialect>org.hibernate.dialect.MySQL8Dialect</hibernate.dialect
<hibernate.naming.implicitStrategy>org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl</hibernate.naming.implicitStrategy
<hibernate.naming.physicalStrategy>org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl</hibernate.naming.physicalStrategy>
<jpa.url>hibernate:spring:com.example?dialect=${hibernate.dialect}&amp;hibernate.implicit_naming_strategy=${hibernate.naming.implicitStrategy}&amp;hibernate.physical_naming_strategy=${hibernate.naming.physicalStrategy}</jpa.url>

Comment From: snicoll

I marked it as resolved as you were commenting on a 4 years old issue about something related to Spring Boot 2.3.x.

Marking my comment as "resolved" without actually providing any kind of solution isn't cool

The issue tracker is not a support forum. If the hint I've provided wasn't enough, please follow-up on StackOveflow or chat with the community on Gitter. You may also want to review the guidelines for contributing.

Comment From: alan-czajkowski

@snicoll should I move my comments over to #23174 ? it's valuable information related to spring-boot.version and having these comments for historical reasons adds value

Comment From: snicoll

should I move my comments over to #23174 ?

Thanks for asking. Those issues are linked so there's no need to.

having these comments for historical reasons adds value

Proper context for an issue do. Questions like this, as I've already mentioned, are to be asked on StackOverflow so that everyone in the community can find/answer them.