codeconsole opened a new pull request, #16224:
URL: https://github.com/apache/grails-core/pull/16224
The class a `beans` closure compiles to is created during compilation and is
not a source file anyone can open. Registering it in
`META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`
therefore required knowing both that it exists and what the compiler decided
to call it — the name follows from the descriptor's own name and package, so it
is not something you can read off anything. Not knowing either produced a
plugin whose beans were silently never registered, which is a poor thing to ask
an author to notice.
The name is settled in `createAutoConfigurationSibling` and nowhere else, so
that is where the entry is now written: into the compilation's target
directory, beside the `grails-plugin.xml` and `grails.factories` already
generated there.
## A module that keeps the file by hand keeps it
Nothing is generated beside it. Two copies of one resource cannot both go
into the jar — Gradle fails the `jar` task outright — and folding the
hand-authored entries into a copy under the build directory would lose them the
moment anyone deleted the file they were, until then, written in.
Such a module is instead **warned at compile time** when the generated class
is missing from its file, so the silent case is gone either way:
```
com.example.GreetingAutoConfiguration is generated from a beans closure but
is not listed in
src/main/resources/META-INF/spring/...AutoConfiguration.imports, so Spring
Boot will not read it.
Add it there, or delete that file once it holds nothing that is not
generated and it will be
written for you.
```
Deleting the file is what opts in. Hand-authored entries have to stay
possible, which is why they are never assumed to be redundant: a module may
register a class from another jar, one annotated with a composed annotation, or
one carrying no annotation at all — the imports file *is* the registration, and
`@AutoConfiguration` only supplies ordering.
**Nothing that builds today builds differently.** All 21 modules in this
repo that keep the file by hand are untouched, `grails-core` among them.
## Scope
Only the sibling generated for a plugin descriptor is registered. A
standalone `@GrailsBeans` class is a source file its author can see, so it
stays registered by hand like any other auto-configuration — the reason for
generating the entry does not apply to it.
## Two modules stop generating it twice
`grails-databinding` and the `beans-dsl-plugin` example applied the
`autoconfiguration-imports` convention plugin, which produced the same entries
a second time. Verified the jars are unchanged from before:
| module | jar entry |
|---|---|
| `grails-databinding` |
`org.grails.plugins.databinding.DataBindingAutoConfiguration` |
| `beans-dsl-plugin` |
`beandsl.example.plugin.{Farewell,Greeting}AutoConfiguration` |
| `grails-core` (hand-authored, untouched) |
`org.grails.plugins.CoreAutoConfiguration` |
The `beans-dsl` example keeps the convention plugin: what it registers is a
standalone class, which is out of scope above.
## Tests
Five cases in a new `AutoConfigurationImportsWriterSpec`, each driving a
real compilation with a target directory, since that is the only thing that
makes the generated file observable: the sibling registers itself;
`autoConfigurationName` registers under the name actually generated; siblings
from separate source units accumulate rather than replacing one another; a
hand-authored file is left alone and its unique entries untouched; a
hand-authored file missing the generated class produces the warning.
`grails-beans-dsl` is green at 170 specs, as are `grails-core`,
`grails-databinding`, `grails-i18n`, `grails-domain-class`, `grails-sitemesh3`,
`grails-controllers`, `grails-url-mappings` and both `beans-dsl` examples.
`./gradlew codeStyle` is clean.
Independent of #16221 — either can merge first.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
