* Removed the automatic document table heading based on the document id.
* Fixed the way 'absolute' links were resolved in `Processor`. A leading `/` for
a link passed into `Processor.resolveLink` really means "resolve as if I am
starting from the documentation root."
* Moved the default logging configuration out of the final jar path. This is to
help with environments that have multiple projects in the same classpath and
therefore may have multiple `logback.groovy` configurations loading.
* Tweaked CSS.
* Added syntax highlighting using SyntaxHighlighter v3.0.83
(see https://github.com/alexgorbatchev/SyntaxHighlighter)
* Modified Directive to have a link to the DocBlock that contains it. Modified
JLPPegParser to account for this change.
* Modified LinkAnchor to include the ASTNode defining it. Also added
LinkAnchorType enum to facilitate different types of links.
* LiterateMarkdownGenerator is now escaping HTML characters in the code sections
and other places it is appropriate.
* Refactored the link resolution process. Added a new method
`Processor.resolveLink(String, TargetDoc)` that now resolves a URL or URL
fragment relative to the current output context. This function also takes over
the job of resolving JLP links to link anchors and generating the correct URL.
LiterateMarkdownGenerator now calls this instead of doing all the work itself.
* To support the syntax highlighter, the JarUtil class from com.jdbernard.util
is included and the syntax highlighter resources are extracted into the output
directory from a resource jar stored in the JLP main jar.
* The CSS and other assets for the output are no longer copied into every
output directory, but now stored at the output root and linked correctly into
the output files.
* Added references to the source file and file type for TargetDocs instead of
computing them on the fly during processing.
* Added logging with SLF4J and Logback
* Added `--version` option.
* Mofidied the input file rules. When an input object is a directory, JLPMain is
adding all the files in that directory and its subdirectories. Now JLPMain is
ignoring hidden files in the directory and subdirs. A file named explicitly on
the command line is still included regardless of if it is hidden or not.
* Documentation continues.
* Added support for multi-line comments to the JLPPegParser grammar
implementation.
* Added a Java sample file.
* Updated test script to add convenience functions for the java test file and
for using a TracingParseRunner for parse runs.
* Added an option, `--css-file`, to allow the caller to specify their own css
file.
* Added basic logic to the Processor class to detect source file types and build
a parser and a generator for that source type. Support currently exists for
the following languages: C (.c, .h), C++ (.cpp, .c++, .hpp, .h++), Erlang
(.erl), Groovy (.groovy), Java (.java), JavaScript (.js).
* Added CSS based on Docco (blatantly copied).
* Updated sample text to better fit the emerging usage patterns. Some of the
things I did to make it render nicely for the Literate output may cause
problems when we go to render API output. I will cross that bridge when I come
to it.
* Added parsing infrastructure to the Generator behaviour to allow a
pre-processing pass over the document. Current the LiterateMarkdownGenerator
is using this to compile a map of `@org` references.
* Tweaked the HTML output slightly.
* Added a layer over the PegDownProcessor in LiterateMarkdownGenerator to
capture and transform `jlp://` links into relative links.
Ideas:
* For literate output, format like Docco, tables like
Doc | Code
-----------|------------
| docblock | codeblock |
| docblock | codeblock |
| docblock | codeblock |
* For javadoc output, maybe create a running 'pure source' object containing
just the code lines. Then run an sup-parser for the language the code is
written in and build a seperate AST for the code. This code AST then gets
tagged onto the overall AST and is used in the generation phase for code
comprehension. Would still need a way to map doc blocks to code blocks. I
could probably use line numbers. In that case I would need to map the original
source line from the commented input to the 'pure source' while processing the
'pure source' and store the original line number in the code AST. That would
give me a reliable way to lookup the closest code structure to a doc block.
* The code AST would need to made of generic pieces if I want to have
language-agnostic generator code. What may be better is to allow the language
parser to create it's code AST however is wants and just have some pluggable
bit of the generator for each language. Would increase generator code
complexity though.
* Updated test data to include additional parsing edge cases.
* Updated `vbs_db_records.hrl` to use `@org` directives.
* Refactored Generator/Emitter dual-object phase concept into one object, the
Generator. The emitter ended up needing basically full visibility into the
generator anyways.
* Implemented `JLPBaseGenerator`, `MarkdownGenerator`, and
`TransparentGenerator`
* Modified the way the parser handles remaining lines to allow it to safely
handle empty lines.
* Added planning documentation regrding the process.
* Updated grammer.
* Refactored the test code a bit.
* Added sample input file from vbs-suite
* Refactored the AST node structure created by the parser.
