This commit concentrates on two related issues: - It adds a new command line switch `--exit-threshold` which allows users specify the threshold value (numeric) which is used to filter out tool exit codes: if reported exit code is below the threshold value, tool simply returns 0. - Restructures exit codes values to have higher value representing more severe condition. This plays nicer with previous point. Currently warning has value 1, error 2, fatal 3 (although fatal is not used currently in the tool). Note that it's not possible to suppress crashes, regardless of whether the threshold is set above the value (250 currently)! Also updated build number to 692.
Exit codes are now better structured to domains and error codes. Also added a debug log statement (available with `--verbose 6` switch) at the end of the run to log the exit code as "seen" by the application.
…pans under certain circumstances. Closes #77. The problem was with appledoc treating single star as bold and single underscore as italics while Markdown treats single star or underscore as italics and double star or underscore as bold. This requires appledoc preprocessing comment text and converting any single star marker to double star. However as Markdown processor doesn't convert markers inside code blocks, this effectively changed the layout in there. To further complicate the issue, appledoc preprocessor doesn't know in advance whether certain part of text will be converted to code block or not. To compensate, appledoc now leaves original markers untouched and uses placeholder strings when converting single stars to double ones. These placeholders are caught and properly handled later on, in generated HTML where detecting code block or span is simple.
There are several ways of adding project settings: - Add AppledocSettings.plist file to one of the paths given to appledoc on command line. If the file is found in a path, it's settings are automatically injected. The same path is also used for source parsing. This allows command line like `appledoc .`. - Add specific path to a file with arbitrary name and .plist extension. The settings from the file are injected, but the file is not used for parsing. In both cases, the .plist file has the same syntax as global settings file, except that project settings allow additional option `--input`, which should be an array of strings, each pointing to a source file or directory. These paths can be relative to the .plist file or absolute (will update online documentation soon with examples). The input option is optional; if not used, command line is expected to have at least one source file or directory.
… files (just about being added).
This was one of much requested features. It allows adding arbitrary files to generated documentation. It's enabled with one or more `--include` switches. All files and directories specified are simply copied to `docs` subfolder within generated HTML files. So basically, you're free to write any HTML or whatever you want included with the generated documentation. But the power lies in special "template" files. These are just normal text files which names end with `-template` (for example `document1-template.html). Extension of these files is not important - they will always be converted to .html! The files can reside on any subpath - the path will be preserved. All such files are processed using the same logic as any other comment, so you can use appledoc comment syntax, including cross referencing any object or member. You can also cross reference these files from "normal" comments (or other documents) by simply writing the filename without `-template` and extension. You don't have to deal with subpaths either, these will be automatically picked up for you! [Online documentation](http://tomaz.github.com/appledoc) is not yet updated, will do it shortly. At this point, it's basic stuff only. As such it has much potential for future (like adding markdown syntax for headings, images and similar - for now just use HTML tags). But at least it's a start and get's work done for the moment. Enjoy and let me know if you find something not working as expected :)
…oper notes. The whole history is available through git, so although nicely formatted what's new section is welcome, it's duplicate, and prone to "forgetting updating it" (happens to me all the time :). Various developer notes are still included in the file until I find a better place to organize them.
…hase. After splitting doc set generation into 3 distinct phases, the 2 new classes were not added to unit tests target resulting in linker errors.
Instead of having a single behemoth class, we're now using separate classes for distinct phases - generation, installation, publishing. This makes the code clearer and allows reuse existing input/output paths mechanism implemented in GBGenerator and GBOutputGenerator.
Reasoning is similar to previous commit.
…ng protocol. Instead, the GBApplicationSettingsProvider class is used. Objective-C can solve "program to interface" rule quite easily through anonymous type and we can as easily mock classes as we can protocols, so having a protocol only complicated development...
…oval of undocumented objects. Due to the fact that we may copy documentation from superclasses, we must remove undocumented members and objects only after processing members, otherwise we would delete overriden methods before getting the chance to copy the documentation.
…ore specific testing in separate files. All unit tests specific to undocumented objects and members were moved to a separate file to keep test cases more understandable and up to the point.
…viding to encapsulate replacements for it's values. This simplifies the rest of the application, reduced code clutter and speeds up as these values don't change during the run!