Add the org.springframework.experimental:spring-native dependency automatically when the org.springframework.experimental.aot plugin is applied

[wilkinsona]

When the org.springframework.experimental.aot plugin is applied, it could automatically add a dependency upon org.springframework.experimental:spring-native to the implementation configuration. This would simplify things a little bit for users and would also remove the need to keep the versions of the plugin and the spring-native dependency in alignment.

[wilkinsona]

This may complicate things from a start.spring.io perspective. This would be the first entry that's just a plugin when generating a Gradle project.

/cc @snicoll

[snicoll]

I think that's fine. We can remove the dependency as part of customising the build for Gradle.

[sdeleuze]

I am not sure we should do that, currently both should always be used together, but that's likely to change since the AOT plugin will be usable without spring-native, see #488.

[snicoll]

When that happens, we can update the plugin to not add the dependency then. What am I missing?

[sdeleuze]

If it is added automatically on Gradle side, we won't be able to use spring-native dependency as a trigger for native related AOT transformations, so I tend to think it should remain explicit (and symmetric between Maven and Gradle).

[wilkinsona]

If it is added automatically on Gradle side, we won't be able to use spring-native dependency as a trigger for native related AOT transformations

Sorry, I didn't realise that was a requirement. That's a good reason to keep the separate dependency declaration.

and symmetric between Maven and Gradle

We used this as a guiding principle in Spring Boot 1.x and it was one of the biggest mistakes we made. A Gradle plugin that's symmetric with Maven won't be idiomatic and, in our experience at least, will become very difficult to maintain. Not directly related to this issue as there's a good reason to keep the dependency declaration beyond symmetry with Maven, but I thought it worth mentioning as I think it would be mistake to keep the plugins symmetrical purely for the sake of it.

Back to this specific issue, it would still be nice to avoid the need for the dependency to have a version when it should match the version of the plugin. Perhaps the plugin could provide some dependency management or a helper method so the user doesn't need to worry about this?

[sdeleuze]

Thanks for your feedback.

@bclozel Any thoughts?

[bclozel]

I thought the main driver behind renaming the build tools as "aot" was that we would consider them for the native and for the JDK use cases?

Taking a step back, we really want the developers to express an opinion that says whether we should include native-related AOT or not. Maybe that dependency is not necessarily the best marker we would like here - would a Gradle DSL option work better in this case?

In any case, we can make things easier by configuring the dependency and/or contributing dependency management for it.

[wilkinsona]

A DSL might be nice. You could do something like this:

springAot {
    native()
}

Or this:

springAot {
     native {
         // Set some native settings here
     }
}

When native has been called, the exact setup – adding a dependency or whatever – becomes an implementation detail.