So, I started looking at the code for the MarkdownService and I see how that seems to work, but I am trying to ensure that I implement ASCIIDoc support such that includes, macros, and processors will work correctly. One issue I see with basing my implementation on the MarkdownService is that it takes a String input and I would like to see if I can make it accept a directory of potentially nested include files... I'm still thinking it through, but @robin if you have suggestions I would be happy to consider them.

Hmmm... The process method takes Project as an input and that contains path, which appears to be the filesystem path to where the data is stored. That should make this easier I think.

@infosec812 thanks for willing to contribute. Project path is not what you want. It is merely hierarchical name of the project. Please check MarkdownRenderer instead, it handles markdown file display and edit. To read other files, use context.getProject().getBlob(blobIdentOfOtherFile).getText() instead. Make sure to handle null return values nicely for getBlob() and getText().

Ah, OK... Asciidoctor expects a traversable directory of files where it can find includes, images, etc... The good thing is they provide an interface DirectoryWalker which I believe can be implemented such that it can traverse and iterate all files in the repository at a given branch/commit. I am working on that today and tomorrow between sessions at J-Fall.

Cheers,

Deven

Traverse all files in repository just for rendering a single asciidoc file is not feasible, as it can be too slow. I guess Asciidoctor should know which include/image file to request during rendering phase, and that file can be requested directly from repository via getBlob method of project with the file path in repository.