jlp/project.properties

#Thu, 29 Dec 2011 15:43:59 -0600
name=jlp
version=1.3a
build.number=0
lib.local=true
release.dir=release
main.class=com.jdblabs.jlp.JLPMain
executable.jar=true
Ground work for include directive, documentation. * 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 2011-12-29 21:45:21 +00:00			`#Thu, 29 Dec 2011 15:43:59 -0600`
Initial commit. 2011-08-22 20:54:38 +00:00			`name=jlp`
Ground work for include directive, documentation. * 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 2011-12-29 21:45:21 +00:00			`version=1.3a`
			`build.number=0`
Initial commit. 2011-08-22 20:54:38 +00:00			`lib.local=true`
Updated version number and build script. 2011-09-06 22:18:39 +00:00			`release.dir=release`
Plain Markdown support. Directory support. * 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. 2011-12-26 05:11:21 +00:00			`main.class=com.jdblabs.jlp.JLPMain`
			`executable.jar=true`