[WIP] Initial proposal for a Spring Boot parent

[gytis]

I've put together an initial proposal for a possible Spring Boot parent addition. I've restructured the project in a following way:

• spring-boot-build - project base containing main repositories and release profile needed for all modules
  • spring-boot-bom - the original spring-boot-bom but now only containing dependencies and inheriting from spring-boot-build
  • spring-boot-parent - inherits from spring-boot-build and includes spring-boot-bom in its dependencyManagement section. For the user convenience it also includes spring-boot-maven-plugin and fabric8-maven-plugin as well as resource filtering. What plugins and configurations should be included here is up for discussion.

This should be backwards compatible with the existing users as spring-boot-bom coordinates did not change and only parts of it moved to its parent (spring-boot-build). This might, however, impede our release process in some unexpected way in case there are some hardcoded values in the scripts. Thus, I don't recommend moving ahead with this for the 2.1.10 release but start reorganisation immediately after it.

[geoand]

Yeah, we would probably need to update Atomist but it shouldn't be much of an effort

[aureamunoz]

Nice work @gytis . LGTM at the moment, the only remark I would do and it's very minor is I don't like the name of the module spring-boot-parent, one could think that parent corresponds to project containing the modules...I agree with doing the 2.1.10 release with the old BOM

[gytis]

@aureamunoz in principal I agree. But the idea here was that this spring-boot-parent would be a parent for the actual applications that our users create. It's the same logic that spring boot has spring-boot-build > spring-boot-dependencies > spring-boot-booster-parent. So in this case me.snowdrop:spring-boot-bom would have a similar role as spring-boot-booster-parent

[gytis]

Alternatively, Erin suggests to have the same spring-boot-bom as before, but instead importing spring-boot-dependencies making them its parent. Then client application would use spring-boot-bom as a parent. For me this sounds like a good way as well, I'm just not used to see *-bom as a parent. That's why instinctively in the first attempt I've created separate bom and parent modules. But I might have the wrong assumption here on what's the correct practice.
What do you think @aureamunoz @cmoulliard @geoand @metacosm @iocanel ?

[aureamunoz]

Ok, thanks @gytis for the explanation, it's what I was thinking right now that from the point of view of users that will be coherent :-)

[geoand]

I know I would be confused to have the BOM as a parent :)

[metacosm]

Can't we use ${project.version} here?

[metacosm]

Tangent to the core issue but is this version tested? See discussion in snowdrop/rest-http-example#111

[metacosm]

Though, I guess, this change would address the need to update all examples so that they are all consistent.

[gytis]

For now I wanted to get the opinion on the general structure. All the values are taken from original spring-boot-bom or latest http booster.

[metacosm]

I'd prefer to use parent in the name if the purpose is for that pom to be used as a parent to applications. BOMs are conventionally used in dependency management sections so I think it'd be confusing to use bom in the name for a parent POM… 😅

[gytis]

I'd prefer to use parent in the name if the purpose is for that pom to be used as a parent to applications. BOMs are conventionally used in dependency management sections so I think it'd be confusing to use bom in the name for a parent POM… 😅

So we could go two ways. Multiple modules as in this PR or renaming spring-boot-bom to spring-boot-parent. I assume the first option would be the preferred one?

[gytis]

Also while we're on a subject of reorganising. What's the situation with #37?

[iocanel]

Shouldn't we import the dekorate bom too?