-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Generate configuration metadata for types in other modules #18366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is working as expected I am afraid. If the source code of However, I can see how that's annoying and how the doc example is misleading. Flagging for team attention. |
Since this is an annotation processor, this is hard to retrieve the JavaDoc from a compiled class. I think this pattern can have a different behavior for the computation of the default value too. Have you planned another way to produce the description which does not suffer from this limitation ? Maybe another annotation that is used to describe the property ? |
@jjoslet I think I wrote exactly that in my previous comment, didn't I? We haven't scheduled anything at this point but I'd like to discuss it a bit more which is why I've flagged it. |
We may be able to find the existing metadata that was generated for |
That will solve the issue for the particular Example in Spring Boot: |
We have metadata for that too. |
Yes, metadata are present but they miss the description.
|
It's a third party type, they don't have description as it's not a |
Since #19500 is closed: My use-case is not to generate metadata for external 3rd-party classes outside my control. I am the maintainer of the jar providing the |
I got that. Generating the metadata and reusing it is covered here too. |
#34210 is related to this. It proposed allowing the configuration processor to consume multiple additional metadata files. |
I am investigating the option to source configuration metadata for any arbitrary types in the form of The next step is to offer a way to run the annotation processor on |
We're brainstorming where to put those files and wondering if This would give something like this:
We're not 100% happy with this just yet. The per-type metadata is only used as a temporary artifact for anyone willing to embed the |
Another option:
|
After some more discussion we've landed on: 4.0.x:
If we need a v2 metadata later:
|
Previously, if a ConfigurationProperties had a nested type or was extending from a type located outside the compilation unit, no metadata discovered on the source code was available (documentation and explicit default value, if any). This typically happens when such a type resides in another module. This commit introduces `@ConfigurationPropertiesSource` as a way to annotate such type and have metadata generated for them in their own module. Type-metadata is generated as one file per type and is reused transparently whenever that type is used. As for module metadata, an additional file can be crafted manually and will be merged when the metadata for the type is generated. The following is an example structure with two types where one has an additional metadata: META-iNF/ spring/ configuration-properties/ additional/ com.example.SourceOne.json com.example.SourceOne.json com.example.SourceTwo.json Those files are used only by the annotation processor and are not meant to be public API. See gh-18366
Closes gh-18366
Closed by 8c56624 |
See gh-18366 Co-authored-by: Phillip Webb <[email protected]>
Spring Boot version: 2.1.8.RELEASE
When using a class imported from a dependency as a
@ConfigurationProperties
, the generated configuration properties meta-data does not contains the description for this class' properties.Scenario to reproduce:
I test the example described in the documentation to create two data sources : https://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-access.html#howto-two-datasources.
The produced
spring-configuration-metadata.json
does not include the description for the properties ofDataSourceProperties
class.Here is a sample of the produced meta-data:
Sample project: demo.zip
The text was updated successfully, but these errors were encountered: