Update spring-dependencies/pom.xml with property spring-boot.version.

[zhanhb]

It seems a little too hard to upgrade spring-boot when working with io.spring.platform:platform-bom.

[snicoll]

This has already been raised in the past and we rejected it.

Consider the use case where you inherit from spring-boot-starter-parent 1.2.5.RELEASE and you set the spring-boot.version to 1.3.0.M5. You shouldn't use that version, really. That's why these versions are set according to the current Spring Boot version.

[zhanhb]

I know spring-boot 1.3.0.M5, but maybe I just wan't to upgrade to 1.2.6.RELEASE.

[snicoll]

Well, change the version in the parent...

[zhanhb]

But platform update is not as frequent as spring-boot.

[wilkinsona]

That's by design: http://docs.spring.io/platform/docs/1.1.3.RELEASE/reference/htmlsingle/#maintenance-release-cycle.

Assuming that there are no problems reported with Spring Boot 1.2.6, a Spring IO Platform 1.1.4.RELEASE that uses it will be released shortly.

[zhanhb]

OK, thanks for replying. Looking forward to the coming RELEASE.

[odrotbohm]

While I am not insisting on the way this get's solved but the main problem persists: if you — by whichever means — consume a parent that by some levels of indirection inherits from Boot's starter POM, there's currently no way whatsoever to control the versions of the Boot dependencies in anything but that parent declaration.

This is especially unfortunate if your projects doesn't control the release or upgrade cycle of that intermediate parent. Also, this is inconsistent to the way dependency management works for everything but Boot. I can override properties, I can use the <dependencyManagement /> section myself to override dependency versions or even shoot my leg of if I want to. That's why I think the "too dangerous" argument is weak one, as it would apply to all other overriding mechanisms as well.

So I'd argue that unless using the property breaks anything , it would just bring the override mechanism for Boot dependencies on par with the dependency override mechanism for 3rd party libraries. I'd also argue it's even safer as it controls all aspects involved: Boot starters, Boot libraries and 3rd party dependencies, so that the override mechanism currently in place is much more likely to introduce something breaking (as the new 3rd party dependency might not work with the current auto-configuration) than a controlled upgrade of all Boot libraries and dependencies.

[snicoll]

What is the rationale of inheriting from spring-boot-starter-parent 1.2.7.RELEASE and actually use 1.3.1.RELEASE? From my perspective, it's simply wrong. The parent provides you base dependencies and plugins management (including sensible settings, e.g. resources filtering). Some of these defaults are actually maintained for backward compatible reason just like the code itself. If we implement what you're asking you could get the plugin configuration of 1.2.x with a 1.3.x runtime (or the other way around).

This is especially unfortunate if your projects doesn't control the release or upgrade cycle of that intermediate parent.

To me, said parent shouldn't use spring-boot-starter-parent at all if the Spring Boot version is meant to be configurable. I know I am not helping but from your description, this is the problem and being able to override the Spring Boot version is just a way to workaround it.

[odrotbohm]

What is the rationale of inheriting from spring-boot-starter-parent 1.2.7.RELEASE and actually use 1.3.1.RELEASE? From my perspective, it's simply wrong.

It could be, but it doesn't necessarily have to. If I am fine with the general build setup that the parent has in 1.2.7, it could just work. The same question could be raised when using Spring Boot 1.2 with Hibernate 5. The latter is even more unlikely to work than the example you gave.

To me, said parent shouldn't use spring-boot-starter-parent at all if the Spring Boot version is meant to be configurable.

That's fine but the Spring Boot parent contains a lot of useful setup the maintainer of the intermediate parent pom doesn't want to replicate (i.e. copy & paste).

I know I am not helping but from your description, this is the problem and being able to override the Spring Boot version is just a way to workaround it.

The problem is that I cannot tweak the version of Spring Boot dependencies the way I can tweak all other dependencies. Because my project refers to some arbitrary company parent pom, I might not even be aware the Spring Boot parent is involved and then wonder why I can't even use <dependencyManagement />.

It all boils down to a "you can break stuff with that" which is — if applied consistently — true and possible for a lot of other means we already expose. Plus the proposed change would actually remove an inconsistency in the way we allow overriding dependency versions. I totally get that we want to be opinionated but that doesn't mean we shouldn't let users override things in case they know what they're doing.

[wilkinsona]

The key difference with the Spring Boot version versus the Hibernate example given above is that it would allow the Spring Boot version to be declared in two different places:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-samples</artifactId>
    <version>1.3.1.RELEASE</version>
</parent>

<properties>
    <spring-boot.version>1.2.8.RELEASE</spring-boot.version>
</properties>

That's horribly confusing, in my opinion. It's far simpler to know that if you are using a particular version of Spring Boot's parent then that's the version of Boot that you're using.

@olivergierke I don't think that the problem you've described above really has anything to do with Spring Boot specifically. It's standard behaviour for Maven and its dependency management when using a parent pom. As @snicoll already suggested, if you want the version of Spring Boot to be flexible, then using it as a parent (or grandparent etc) probably isn't the right way to go.

[odrotbohm]

I feel like you're looking at it from a very narrow point of view: Boot itself and a project that uses Boot's parent pom directly. In those cases, it of course it doesn't make any sense to override the property.

In the majority of In real-world projects however the relationship is usually not as direct and thus, the confusion you perceive doesn't really exist (see below). If I tweak I 3rd party dependency's version explicitly, it's defined in two places as well: there's a property in the dependencies BOM and in my local project.

Assume a project pointing to an arbitrary parent pom

<parent>
    <groupId>com.acme</groupId>
    <artifactId>company-parent</artifactId>
    <version>4.6.3</version>
</parent>

Now assume that this makes Spring Boot 1.3.0.RELEASE appear in my project. If I now can tweak the Boot version like this:

<properties>
    <spring-boot.version>1.3.1.RELEASE</spring-boot.version>
</properties>

I'd now get Spring Boot 1.3.1 and I don't think this is confusing at all. I'd even argue that anything but that is confusing. I am set up with a default version for Boot by the parent and I don't care about its means to do so. It could just have used a property itself and declared a <dependencyManagement /> section listing all the dependencies explicitly itself, in which case the problem doesn't exist. It could also by accident be using the Boot parent of a particular version.

Even if I am familiar with the way the Boot parent works, look up the spring-boot-dependencies the first property I find declared is spring-boot.version, try to use that just the way I can use all other properties, it just doesn't work. That's surprising. Exactly that is proposed in the reference documentation: use the parent, lookup the property, customize. Except that it works for all properties except spring-boot.version.

I am not arguing to make anything confusing, I just like the mechanisms to work consistently and as advertised, even if it's a special case in the first place. But that is overriding dependency versions in general.

[wilkinsona]

I'd now get Spring Boot 1.3.1

You won't. You'll dependency management for Boot 1.3.0 alongside Spring Boot 1.3.1's parent that provides plugin definitions, etc. That mixture of two different versions is what I consider to be horribly confusing and a possible source of very-hard-to-track-down bugs.

The difference with all the other dependencies is that the version controls everything and you aren't left with a mixture of versions.

[wilkinsona]

Even if I am familiar with the way the Boot parent works, look up the spring-boot-dependencies the first property I find declared is spring-boot.version, try to use that just the way I can use all other properties, it just doesn't work. That's surprising.

Agreed. IMO, we should remove the property and hardcode the version in the handful of places where it's currently used. @snicoll, WDYT?

[snicoll]

+1

[odrotbohm]

You won't. You'll dependency management for Boot 1.3.0 alongside Spring Boot 1.3.1's parent that provides plugin definitions, etc.

I'd get Spring Boot JARs 1.3.1, I'd get Spring Boot Starters in 1.3.1 and I'd get 3rd party dependencies in the version they're defined in 1.3.1. I'd get a Spring Boot 1.3.1 at runtime. Which is exactly what I want.

The plugin definitions are configuration setup of non Spring Boot plugins plus the Spring Boot one (which ironically uses the property). So what conflicting scenarios could be arising here? Isn't the point that by overriding the spring-boot.version the chance I create a breaking setup is significantly lower than by overriding an individual 3rd party dependency? I mean I update 3rd party dependencies alongside the Boot jars.

Anyway, I think I've stated my case that I don't think the usage of the property creates more risk of confusion (but actually reduces it) than any of the other properties declared currently and why we'd want to actively prevent a valid use case from having a solution.