Modularize codebase to reduce the size of a typical Spring Boot application and provide stronger auto-configuration signals.
Comment From: DanielLiu1123
Wow, this is great!
Comment From: xenoterracide
Without looking deeply at this I'm hoping that you're making sure that your new jar names are compatible in a way that would allow creating a Gradle version catalog programmatically. For example in version 3 of spring boot the artifacts spring-boot and spring-boot-test cannot be converted directly to a Gradle version catalog. Spring itself is called spring-core which works with spring-test and so would spring-boot-core .
Comment From: philwebb
@xenoterracide We're not planning to rename spring-boot or spring-boot-test since that's likely to make it harder for folks to upgrade. What's wrong with those module names that means they cannot be converted directly to a Gradle version catalog? Can you link me to some relevant documentation?
Comment From: xenoterracide
Gradle version catalogs convert things into objects and properties
So if you were to write an automatic generation
You end up
spring-boot spring-boot-test
Which would then attempt to generate the object accessors
spring.boot spring.boot.test
Which doesn't work because the first one is not the final object and so cannot be the appropriate provider.
I would suggest simply giving it a go.
https://docs.gradle.org/current/userguide/version_catalogs.html#sec:accessing-catalog
I personally wouldn't consider a jar rename to be a big deal especially with most people going through the starters. Especially at a major version. I see this as her one chance to make the break for years. I've probably already said this but spring core has the convention that you do not... Maybe best to follow spring cores convention...
Comment From: xenoterracide
Gradle version catalogs convert things into objects and properties
So if you were to write an automatic generation
You end up
spring-boot spring-boot-test
Which would then attempt to generate the object accessors
spring.boot spring.boot.test
Which doesn't work because the first one is not the final object and so cannot be the appropriate provider.
I would suggest simply giving it a go; I don't see a way that you could automatically convert the current artifact names without adding something to them to simply avoid the conflict.
https://docs.gradle.org/current/userguide/version_catalogs.html#sec:accessing-catalog
I personally wouldn't consider a jar rename to be a big deal especially with most people going through the starters. Especially at a major version. I see this as her one chance to make the break for years. I've probably already said this but spring core has the convention that you do not... Maybe best to follow spring cores convention...
Comment From: philwebb
I think I see what you mean. The spring-boot module overlaps with spring-boot-<thing> and Gradle wants spring.boot to be a container object that contains all the nested (<thing>) items. We'll have to discuss this and see if the benefit of upgrade pain is worth it. We also have #29588 which might solve the problem in a different way.
Comment From: xenoterracide
Well, this might help you solve #29558. Because if the community were to do it we would need it to work this way and I would think if you guys were writing a version catalog plug-in you would probably approach it the same way instead of hand coding it.
Also, for those of us already using version catalogs we would only have to make this change in a singular place because you don't actually have to change the container object name to change the artifact location. Whereas the rest of this modularization is actually going to be really painful because we're going to have to write a whole lot more code to manage it.
If it helps I can point you to my version catalog I think there are only a handful of artifacts that would really need to be renamed in this regard.
Thank you for taking this under consideration.
Comment From: philwebb
We discussed the Gradle version catalog issue today and we think that renaming modules would cause too many upgrade issues for us to take it on. We have several modules that overlap (such as spring-boot/ spring-boot-test, spring-pulsar / spring-pulsar-reactive, spring-boot-starter / spring-boot-starter-test), we also have been trying to keep package names aligned with modules names and changing org.springframework.boot to org.springframework.boot.core would be quite a large change to make.
Although it can't be as easily automated, the version catalog file seems to allow different names to be used for the library. The docs show this with the groovy modules which they have named groovy-core.