maxandersen
commented
1 year ago @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.
gsmet
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-pluginoutput 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 https://github.com/quarkusio/quarkus/issues/19020 .
/cc @maxandersen