Unlike other Spring Boot goals, process-aot and process-test-aot run on Maven reactor projects

[ls-urs-keller]

When running in multi module maven projects, the aot phase should not run on modules with type POM

[snicoll]

It won't, unless the spring-boot-maven-plugin is applied or you have configured an execution in the parent in plugins rather than pluginsManagement.

I think this sort of change is actually hiding a build setup issue. See also #33184.

Can you please check your build and get back to us with a reason for this change?

[ls-urs-keller]

It won't, unless the spring-boot-maven-plugin is applied or you have configured an execution in the parent in plugins rather than pluginsManagement.

That's the case, but it is also a valid use case assuming a common parent project and N services all similarly configured inheriting dependencies and plugins from the parent.

We do this this way already for the repackage goal:

spring-boot/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/main/java/org/springframework/boot/maven/RepackageMojo.java

Line 198 in 1770f06

if (this.project.getPackaging().equals("pom")) {

Otherwise we would have to remove the spring-boot-plugin from <build><plugins>... and repeat it in every module. Or add a skip in the parent and set that to false in all the modules.

The suggestion here is to align the behaviour process-aot with what's already a reality in repackage goal which also skips over reactor modules.

[snicoll]

Are all your sub-modules spring boot applications?

We do this this way already for the repackage goal:

I am aware of that and I've explained above why I'd like to get a bit more detail about the setup.

[ls-urs-keller]

Are all your sub-modules spring boot applications?

We do this this way already for the repackage goal:

I am aware of that and I've explained above why I'd like to get a bit more detail about the setup.

We also have library projects not spring boot, for those we add a repackage skip =true.
But those tend to be fewer.

Of course, we could do it the other way around adding a skip = false for those that need repackaging/aot-processing.

The process-aot goal behaves inconsistently with respect to the repackaging goal within the same plugin, maybe the solution is to remove the code from repackaging, but that would probably break things.

[snicoll]

Of course, we could do it the other way around adding a skip = false for those that need repackaging/aot-processing.

You could rather configure the execution for the plugin in your parent with whatever settings you need in pluginManagement and then add the plugin definition in the projects that need it. That's what start.spring.io does with our parent for a fresh project.

And your library projects would not have any reference to Spring Boot at all. This is a better arrangement IMO as the spring boot plugin is only applied where it is necessary rather than applying it in the reactor for all modules and skipping things.

The process-aot goal behaves inconsistently with respect to the repackaging goal within the same plugin,

run does not skip on pom projects. Checking for pom always was an escape hatch for those who were applying a plugin globally in the reactor.

That being said, we could add this check, I'll check with the rest of the team.

[ls-urs-keller]

And your library projects would not have any reference to Spring Boot at all. This is a better arrangement IMO as the spring boot plugin is only applied where it is necessary rather than applying it in the reactor for all modules and skipping things.

We are using flatten plugins for this, since the libraries we publish need to have a flat pom anyway we configure it to remove most things except the deps. But I guess that's opinionated.

run does not skip on pom projects. Checking for pom always was an escape hatch for those who were applying a plugin globally in the reactor.

True, run doesn't skip.

[wilkinsona]

@ls-urs-keller Thanks very much for making your first contribution to Spring Boot.