Rename repository and artifacts to align with Spring Boot naming conventions

[wilkinsona]

Hi. It's great to see you participating in the Spring Boot ecosystem. We have a section in the Spring Boot reference documentation with some guidelines about artifact naming. The section talks specifically about starters but the intent is that it is more generally applicable to projects and artifacts in the Spring Boot ecosystem.

Would you please consider renaming this repository and the artifacts it produces to align with the guidelines? Similar updates would be welcome in several other repositories in the Snowdrop organisation.

[cmoulliard]

some guidelines about artifact naming

Excepted this section Andy - @wilkinsona, I don't see any specific guidelines about artifact naming. Can you tell us where such info/section is defined please and what is wrong into our snowdrop gtihub org ?

The only thirdparty starter that we have, which is also used by Spring Boot, is the narayana project and it follows your convention narayana-spring-boot - https://github.com/snowdrop/narayana-spring-boot

[wilkinsona]

That is the section I referred to above when I said “the intent is that it is more generally applicable to projects and artifacts in the Spring Boot ecosystem”.

The problem in this org is that there are many projects and artifacts named spring-boot-*. This is particularly problematic when looking at jar files, for example those packaged in BOOT-INF/lib as there’s no way to differentiate between first- and third-party artifacts.

[wilkinsona]

I think it might also be worth pointing out that this isn't something that's specific to Spring Boot. It seems to be a broadly adopted convention, for example:

• Infinispan's module that integrates with Hibernate is called infinispan-hibernate
• Spock's module that integrates with Spring is called spock-spring
• Dropwizard's module that integrates with Jackson is called dropwizard-jackson
• Jersey's module that integrates with Kryo is called jersey-media-kryo

There are many more, but those above represent both independent and "commercial" open source projects following the pattern that the Spring Boot ecosystem encourages.

[cmoulliard]

• The only starter's project of the snowdrop org is narayana-spring-boot which follows your convention. No changes are needed then ?
• All the spring-boot-xxx-booster repos concern Quickstart used to play with Spring Boot on Openshift, Kubernetes. They will never been used as starter and by consequence will never appear under boot/lib. So, do we have to rename them ?
• spring-boot-cloud-devex is an internal project used as Lab, R&D to do develop an Operator for Spring Boot deployment on K8s/openshift and to have a nice interactive's mode client. I can rename it to cloud-spring-boot-devex to avoid any ambiguity.
• Concerning the BOM project, spring-boot-bom, we are discussing to rename it to snowdrop-bom. Is it ok for you @wilkinsona ?

[wilkinsona]

The only starter's project of the snowdrop org is narayana-spring-boot which follows your convention. No changes are needed then ?

As I tried to explain above, the intent is that convention is more broadly applicable than just starters. We would like it to be followed by all third-party modules in the Spring Boot ecosystem, not just starters.

They will never been used as starter and by consequence will never appear under boot/lib. So, do we have to rename them ?

Yes, please. We'd like all modules, irrespective of their nature, to follow the convention.

I can rename it to cloud-spring-boot-devex to avoid any ambiguity.

While I welcome the artifact's name no longer starting with spring-boot, I'm not sure that the new name removes much ambiguity. cloud- is a very generic term. Would it not be better to start all Snowdrop modules with snowdrop-?

Concerning the BOM project, spring-boot-bom, we are discussing to rename it to snowdrop-bom. Is it ok for you @wilkinsona ?

Yes. Thank you.

[jclingan]

Andy, thanks for reaching out. We definitely want to be good partners in the Spring ecosystem. It makes sense for us to follow along the naming conventions and we'll work in that direction. One exception for now will be our boosters (runnable examples) because it fits the naming convention for boosters we have defined across all our runtimes (with dependencies on that convention). We can definitely consider renaming them in the future, but in the short term I we have a need to keep the examples named as-is.

[wilkinsona]

That's great. Thanks, @jclingan.