Our ProcessAot has no property to set the profiles used for AOT, while the Maven ProcessAotMojo has a property named profiles to do that. I think the Gradle task should have it, too.
There's a workaround to set the profiles (args('--spring.profiles.active=profile-a,profile-b')) but it's not pretty.
Comment From: wilkinsona
The same applies to BootRun which also does not have a setting specifically for profiles. Both BootRun and ProcessAot are sub-classes of JavaExec and, thus far, we've opted to make use of JavaExec's configurability:
As the BeanFactory is fully prepared at build-time, conditions are also evaluated. This has an important difference compared to what a regular Spring Boot application does at runtime. For instance, if you want to opt-in or opt-out for certain features, you need to configure the environment used at build time to do so. To this end, the processAot task is a JavaExec task and can be configured with environment variables, system properties, and arguments as needed.
I think this has served us well. Given the configurability of JavaExec, I'm not sure that it's a good idea to offer settings for Boot specifics. It potentially gets quite complicated as we'd have to figure out how to merge or combine settings when they've been provided as profiles and, for example, as command line arguments.
Comment From: mhalbritter
It potentially gets quite complicated as we'd have to figure out how to merge or combine settings when they've been provided as profiles and, for example, as command line arguments.
Good point, i can see that this will get quite hairy.
Comment From: snicoll
+1 I don't think we should do anything special for processAot that we haven't done for bootRun. Gradle is flexible enough to offer what users need IMO.