-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Rework how configuration doc generation works #35439
Comments
@gsmet here is the thread I mention about considering recording the configuration properties in a more readily machine readable format. This would benefit not just (incremental) doc generation but also be immensely useful in other tooling (IDE's, cli's etc.) as they would not need to (re)implement the annotation parsing and handling logic. https://groups.google.com/g/quarkus-dev/c/JXvndoAsekQ/m/YD4K0LYaAwAJ The thread back then died out as I wasn't at the time fully grokking the intricate details of the configuration and it was also before the many improvements and addition of flexibility in config model was added - I'm now more than ever convinced having this recorded in the jars in a way that can then be more easily processed would be an overall improvement. |
A good example of what we are doing wrong: #37639 |
The config doc generation is a problem for the Gradle build cache: we are generating files that are outside of the module boundaries and these files are shared across several modules.
Thus when the
maven-compiler-plugin
output is cached, it's actually impossible to include these files in the cache: when restored from the cache, the files are missing and we end up with an error in the doc generation because these files are missing.We should entirely rework how these files are generated and consumed:
Also, it might be a good opportunity to actually merge the properties between the runtime and deployment module and include a metadata file containing the doc into the jar together with the other extension metadata.
Apparently, Spring and Camel are using a XML format for that.
This part is a bit orthogonal to the original goal but probably something we should have in mind when designing this stuff.
Also I think, we should separate the doc generation from the extension plugin and also exposes it in a Maven plugin that could be used by applications, and not only extensions.
See #19020 .
/cc @maxandersen
The text was updated successfully, but these errors were encountered: