Config annotation updates - #1994
Conversation
… and config stuff
| @@ -0,0 +1,44 @@ | |||
| name: Config Documentation | |||
There was a problem hiding this comment.
What is the idea behind this workflow? Who will be checking/consuming generated artifacts?
There was a problem hiding this comment.
Good question! I had put together this whole @config annotation a couple years ago, but never really polished it up. The dream was to have some way to generate all our configuration documentation based on the source code, and to have it produce the doc for Java and for C. In some futuristic world, we'd run this workflow when we release Aeron, so as to provide a nice big document with all the configuration options in one place.
| /** | ||
| * Converts Javadoc markup (inline tags, HTML) in description strings to Markdown equivalents, | ||
| * and strips block Javadoc tags such as {@literal @}return, {@literal @}param, etc. | ||
| */ |
There was a problem hiding this comment.
Using regex to parse HTML? Why?
There was a problem hiding this comment.
:-) So... one of the reasons I revisted this after 2 years was that it seemed like a reasonable project against which to kick the tires of Claude. When I asked it to build me something that would sanitize the javadoc to make it more fitting for a .md file, this is what it came up with. I know there's no HTML in our javadoc, but it didn't seem like it was hurting anything to leave in the code it came up with.
|
@nbradac Have you looked at the https://github.com/asciidoctor/asciidoclet? |
|
Also https://logging.apache.org/log4j/tools/log4j-docgen-asciidoctor-extension.html might be useful. |
…ate github actions where appropriate
|
The other thing that is still TODO is the contents of the CDriverConfiguration class. All that javadoc was generated by Claude, and it... did a terrible job. It mentions java objects all over the place. |
No description provided.