Have created a repository for the job: pipeline-steps-doc-generator. Reviews on this repository is welcome!
A bit of background on the implementation:
I started with an implementation that extended the backend-extender which worked well for not only scanning the maven repository for plugins, but also identifying the Pipeline steps. The problem with this approach manifested when it was time to dive into the parameters and their documentation. Since essentially the backend-extender treats each plugin separately, there wasn't a good connection between what the parameters of the plugin could be. For example, the 'checkout' step provides different options based on what plugins are installed in Jenkins; the global documentation should include all options. Trying to provide this level of detail was pretty much impossible. I decided to simulate a PluginManager to take advantage of all the heavy lifting of linking, and eventually listing the plugin steps exactly as it's done in the Snippetizer. (There's the secondary benefit that the asciidoc piece could be easily converted to a new endpoint similar to DSLD in the workflow-plugin)
Going with a hybridized approach appeared to solve my problems: use the MavenRepository benefits from backend-extender to create my "plugins" and my new PluginManager to create the new documentation. However, I hit another issue with severely incompatible jar files between update-center2 and jenkins: update-center2 uses a deprecated google-collections jar while jenkins uses the replacement option guice. Unfortunately, there is no overlap for the particular methods used in these jars in either releases of collections or in guice. I'm of the opinion that we should update update-center2 to use guice since Google Code where google-collections is shutting down. This was out of scope for this work and I needed something to work for the jenkinsio release, I created a jar with all the maven repository connections and setup within the "scripts" folder. All this does is access maven, and download the hpi files to a "plugins" folder. This isn't the ideal solution to this problem, but until update-center2 is able to updated, it works.
Along with these other restrictions, I found the positive/negative that you can't have a Jenkins with every single possible plugin installed. While this is likely good news for anyone who has to admin Jenkins, it means there needs to be a list of inclusions or exclusions so we know what plugins to scan for documentation generation. Currently I'm restricting documentation to the list of plugins defined in the workflow-plugin COMPATABILITY.md file. Since there could be plugins made compatible in the future/there might be more out there already, I'm doing future work to make that list a configuration file.
The new Jenkins,io website has nifty hooks to go out and pull down external sources. I have a working changeset to add the results as another source. That'll be pending this job's results.