Currently, Livedoc reads Spring annotations to know the structure of the API. It must exactly follow the Spring documentation to interpret everything about the methods and the annotations. Pushed to the extreme, this means Livedoc must re-implement the part of Spring that reads the user configuration, and inject this configuration into the Livedoc object model.
This is hard labor, and potentially inaccurate.
Considered solution
Reading the Spring-parsed configuration directly from the Spring context would be both easier and more accurate.
That being said, using the power of the Spring context comes at a cost. For now, we could somewhat easily implement a Gradle plugin to generate the doc at compile time (issue https://github.com/joffrey-bion/livedoc/issues/57). The only live dependency on Spring is the ObjectMapper. It could be acceptable to manually duplicate its configuration for the sake of a compile-time doc generation, which opens the door for even cooler things like code generation (issue https://github.com/joffrey-bion/livedoc/issues/55).
With a dependency on the full Spring context, this means we would have to spawn a server to be able to generate this offline documentation, and potentially generate code. We must first look for ways to start a Spring context at compile time before thinking about using it to generate the doc. It may be possible since Spring Boot unit tests do exactly this.
What's wrong right now
Currently, Livedoc reads Spring annotations to know the structure of the API. It must exactly follow the Spring documentation to interpret everything about the methods and the annotations. Pushed to the extreme, this means Livedoc must re-implement the part of Spring that reads the user configuration, and inject this configuration into the Livedoc object model.
This is hard labor, and potentially inaccurate.
Considered solution
Reading the Spring-parsed configuration directly from the Spring context would be both easier and more accurate.
Maybe we could find some inspiring code from Spring actuator, which exposes some of the Spring configuration as a web API: DispatcherServletsMappingDescriptionProvider.java
The problem
That being said, using the power of the Spring context comes at a cost. For now, we could somewhat easily implement a Gradle plugin to generate the doc at compile time (issue https://github.com/joffrey-bion/livedoc/issues/57). The only live dependency on Spring is the
ObjectMapper. It could be acceptable to manually duplicate its configuration for the sake of a compile-time doc generation, which opens the door for even cooler things like code generation (issue https://github.com/joffrey-bion/livedoc/issues/55).With a dependency on the full Spring context, this means we would have to spawn a server to be able to generate this offline documentation, and potentially generate code. We must first look for ways to start a Spring context at compile time before thinking about using it to generate the doc. It may be possible since Spring Boot unit tests do exactly this.