feature - #14017 - add back Micronaut support to Grails 7 with optional plugin

[jdaugherty]

Fixes #14017

1. Adds back support by having the user add grails-micronaut as a dependency and micronautPlatformVersion as a gradle property
2. updates documentation & includes instructions for how to add support
3. adds a feature to forge to add micronaut support to grails app

[jamesfredley]

@amacleay-cohere @ysb33r @rlconst latest update on Micronaut support for Grails 7

[jdaugherty]

@graemerocher or @sdelamo if either of you have any feedback on this change, it would be helpful.

I am not as familiar with the micronaut project dependencies - for example, should the micronaut cache library still be included? I also took the approach that Grails 6 took: the gradle plugin has some logic to make it just "work" for the end user.

The tests are limited in grails-core, but they are passing. My guess is we'll merge this and then make any incremental changes if there's specific feedback.

[matrei]

Some questions and suggestions.

[jdaugherty]

The scaffolding failure was caused by the setters() having @Autowired and not being invoked by the micronaut bean initialization process. Switching to field based fixes that issue.

I'm still concerned about the lack of test coverage, other than the functional test apps, but I think users can try this out in the RC2 and we can go from there.

@jamesfredley @matrei the bean wiring will likely have further issues - anywhere we use a setter with @Autowired doesn't appear to work when grails-micronaut is included. Switching to constructor based initialization worked for the one failure, but there are other examples in the code base that don't use constructor initialization. A work around would be to ignore those beans by default in the EnableMicronaut annotation. Some examples of this:

1. RequestForwarder trait
2. ResponseRedirector trait
3. ResponseRenderer trait
4. TransactionManagerAware interface
5. HibernateConnectionSourceFactory
6. MongoDatastore
7. AggregateTimestampProvider
8. DefaultConstraintRegistry
9. AbstractConnectionSourceFactory
10. EventBusAware
11. GrailsInterceptorHandlerInterceptorAdapter (explicit call in the grails plugin won't matter)
12. RestResponder
13. AbstractVndErrorRenderer
14. HalJsonRenderer
15. AbstractLinkingRenderer
16. DefaultRendererRegistry
17. ResolvableGroovyTemplateEngine
18. JsonViewTest
19. ParamsAwareLocaleChangeInterceptor
20. DefaultRequestStateLookupStrategy
21. GrailsWebDataBinder
22. DefaultDataBindingSourceRegistry
23. GrailsConventionGroovyPageLocator
24. GroovyPageViewResolver
25. TagLibraryInvoker
26. UrlMappingsHandlerMapping

A lot of these seem related to a change to support multiple message sources (438d2e0)

Do we fix these to say it's supported? Prior versions of grails had a limited number of micronaut beans, so the grails beans weren't a micronaut bean by default. I'm skeptical people were accessing these beans from micronaut, so we may be able to make this change gradually.

[matrei]

It seems moving to constructor injection created another issue?
https://ge.grails.org/s/uvcrhvfabv75a/failures#1

[jdaugherty]

It seems moving to constructor injection created another issue?

https://ge.grails.org/s/uvcrhvfabv75a/failures#1

Odd, this didn't fail locally when I ran through all of the tests. Will take a look.

[jdaugherty]

@matrei This should be fixed now (https://ge.grails.org/s/6nvk6sdfjpzre)

[jdaugherty]

The forge failures are b/c of the asset pipeline depending on the grails-dependencies-web and we have moved the i18n plugin. I'd rather merge this + publish a new asset pipeline + update the version of the asset pipeline than try to add an exclude for that library. @jamesfredley @matrei thoughts?

[jamesfredley]

@jdaugherty Since you need this merged and published to use the new i18n coordinates to then update and release asset-pipeline, I think we can ignore the failures.

[jdaugherty]

I'll publish an asset pipeline release once we get sign off on this then. @matrei / @jamesfredley let me know when you think this is ready.