* Further documentation.
* Decided to add an `include` directive. This will have reprecussions directly
for the JLPPegParser, Directive, and LinkAnchor classes. Include needs more
semantic meaning than we currently have in the process because the author
needs some way to understand what is being included. If you include an org
link defined earlier does it include the whole file? Just that doc block? Both
may be the desired behavior in different situations, but I do not want to add
a complex syntax for selecting, just name the link. Therefore there must be
something about the link that determines how much in included. This means we
need more information in LinkAnchor, some link `type` at a minimum. My current
thought is:
* @org defined links--this is the only type of LinkAnchor defined right
now--always bring the whole DocBlock when they are included.
* A new type of link anchor, call them source file links, bring the whole
file when they are included. These types of anchors would be automatically
created by the parser/generator (have not decided where it belongs yet).
The whole SourceFile would need to be included, but we do not want to emit
the normal header for the file so we may have to do somthing about the
initial emit method.
* Additional types of link anchors arise when we add language awareness to
the process. In my current vision we will automatically add link anchors
of different types when we parse code sections (function definition, class
definition, etc.) and the include directive would bring in all the
DocBlocks related to that code node.
* Additional types of link anchors will arise when we implement the @api
directive, we will think about that in the future.
* Updated the JLPPegParser to recognise include directives.
* Added the include directive to Directive.DirectiveTypes
* 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.
* Upgraded build common to version 1.9.
* Updated the release target in build.xml to take advantage of the new features
of common build 1.9. The release target now copies over the libs and release
resources.
* JLPMain now recognises directories in it's input list. It will add all the
files in a given directory to the input list (including files in abitrarily
nested subdirectories).
* Abstracted the parser behavior further. Processor no longer needs to know
about Parboiled ParseRunners and can use non-Parboiled parsers.
* Created the JLPParser interface to support the new parser abstraction.
* JLPPegParser implements the new interface trivially by creating it's own parse
runner and calling it with the input given.
* Added MarkdownParser, which does not actually parse the file, just creates the
bare-bones SourceFile object needed for the generator to emit the Markdown
contents.
* 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).
* The generators originally had two phases, *parse* and *emit*. The *parse*
phase allowed the generator to walk the AST for every document noting things
it would need when emitting output. So the *parse* phase looked over every
input document before the *emit* phase ran. During the refactor this changed
and for each file the *emit* phase was running immediately after the *parse*
phase, when it should have been run only after all inputs had been through the
*parse* phase.
* Fixed a type in the ``LiterateMarkdownGenerator``: an extra '`/`' was being
inserted into the url for link targets.
* Refactored the overall process flow. Instead of ``JLPMain`` handling the
process, it now reads the command line options and defers to ``Processor`` to
handle the actual process. The ``Processor`` instance is responsible for
processing one batch of input files and holds all the state that is common to
this process.
* ``JLPBaseGenerator`` and generators based on it are now only responsible for
handling one file, generating output from a source AST. As a consequence
state that is common to the overall process is no longer stored in the
generator but is stored on the ``Processor`` instance, which is exposed to the
generators.
* Generators can now be instantiated directly (instead of having just a public
static method) and are no longer one-time use. Now the life of a generator is
expected to be the same as the life of the ``Processor``.
* Fixed inter-doc link behaviour.
* Created some data classes to replace the ad-hoc maps used to store state in
the generator (now in the ``Processor``)
* `relative-path-root` option added. This facilitates situations where the
current directory of the invocation context is different than the working
directory of the program. This is required to use `jlp` with tools like
*Nailgun*, which keeps a persistant `java` process running and proxies new
invocations to the existing process.
