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

Comment From: 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 https://github.com/spring-projects/spring-boot/issues/33184.

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

Comment From: 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: https://github.com/spring-projects/spring-boot/blob/1770f065a5428f059b9659545e4ecbcdf7baa9bd/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/main/java/org/springframework/boot/maven/RepackageMojo.java#L198

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.

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: wilkinsona

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