Updated doxygen

Makefile.am

@@ -67,6 +67,10 @@ nobase_dist_data_DATA = tsk3/sorter/default.sort tsk3/sorter/freebsd.sort \
 
 api-docs:
 	doxygen tsk3/docs/Doxyfile
+	doxygen framework/docs/Doxyfile
+	doxygen bindings/java/doxygen/Doxyfile
+
+framework-docs:
 
 man-html:
 	cd man;build-html

bindings/java/doxygen/main.dox

+/*! \mainpage The Sleuth Kit Java Bindings Developer's Guide and API Reference
+
+<h3>Overview</h3>
+
+These classes allow Java programs to access data extracted by The Sleuth Kit.
+
+The Sleuth Kit is primarily a C/C++ library and set of command line tools. These classes allow programs to obtain the data that TSK can produce.   The typical steps would be to use JNI to cause the TSK library to create and populate a SQLite database.  The Java classes then directly open the SQLite database and perform queries on it. 
+
+Expand on this to mention what classes to use, etc.
+
+*/
+
+

framework/docs/Doxyfile

@@ -1301,7 +1301,7 @@ SKIP_FUNCTION_MACROS   = YES
 # If a tag file is not located in the directory in which doxygen 
 # is run, you must also specify the path to the tagfile here.
 
-TAGFILES               = 
+TAGFILES               = libtsk_doxygen.tag=../api-docs
 
 # When a file name is specified after GENERATE_TAGFILE, doxygen will create 
 # a tag file that is based on the input files it reads.

framework/docs/module_dev.dox

@@ -17,7 +17,7 @@ The framework source code has some sample modules that you should refer to for e
 
 
 \section mod_build Building the Module
-The module will be written as a dynamic library.  This document assumes that you know how to configure your compiler and development environment to make a dynamic link library. 
+The module will be written as a dynamic library.  This document assumes that you know how to configure your compiler and development environment to make a dynamic link library.  The framework will not allow multiple modules with the same name, so you may want to incorporate your project or company name into the module name to prevent collisions.
 
 You will need to include the framework header file to get access to the framework classes. 
 
@@ -25,12 +25,14 @@ You will need to include the framework header file to get access to the framewor
 
 You should be able to find this header file by ensuring that the TSK_HOME environment variable is set to the root of TSK (in a Windows environment) and that $TSK_HOME and $TSK_HOME/framework are in the include search path. 
 
-Next, you need to define several function that the framework will call when it uses the module.   Those are described in the following sections. 
+Next, you need to define several functions that the framework will call when it uses the module.   Those are described in the following sections. 
 
-\subsection mod_setup_init Module Initialization
The <tt>initialize</tt> function is where you perform one time module configuration tasks such as validating input or output folders or establishing a connection to an external system such as a database server.
-The module initialization function must be implemented and it must have the following signature:
+\subsection mod_setup_init Module Initialization
 
-<pre>TskModule::Status TSK_MODULE_EXPORT initialize(std::string& args)</pre>
+The <tt>initialize</tt> function is where you perform one time module configuration tasks such as validating input or output folders or establishing a connection to an external system such as a database server.
+The module initialization function must be implemented and it must have the following signature:
+
+<pre>TskModule::Status TSK_MODULE_EXPORT initialize(const char *args)</pre>
 
 The function takes a string argument, which  you supplied in the pipeline configuration file. It returns a status which should be TskModule::OK or TskModule::FAIL.  Returning TskModule::FAIL will indicate a fatal problem and (in the default implementation) will cause the pipeline to terminate. 
 
@@ -38,7 +40,7 @@ The function takes a string argument, which  you supplied in the pipeline config
 If your module will be running in a file analysis pipeline, then it must implement the <tt>run</tt> function. This function will be called for each file that is run through the file analysis pipeline.   It should have the following signature:
 <pre>TskModule::Status TSK_MODULE_EXPORT run(TskFile * pFile)</pre>
 
-The function is passed a pointer to a file and it must return either TskModule::OK, TskModule::FAIL, or TskModule::STOP.  TskModule::OK should be returned if the module analyzed the file or decided that it did not need to analyze the file.  TskModule::FAIL should be returned if the module tried to analyze the file, but was unable to.  A TskModule::FAIL return value will be logged, but the pipeline will still continue to be analyzed.   TskModule::STOP should be returned if the module wants the pipeline to stop processing this file. 
+The function is passed a pointer to a file and it must return either TskModule::OK, TskModule::FAIL, or TskModule::STOP.  TskModule::OK should be returned if the module analyzed the file or decided that it did not need to analyze the file.  TskModule::FAIL should be returned if the module tried to analyze the file, but was unable to.  A TskModule::FAIL return value will be logged, but the pipeline will still continue to be analyzed.   TskModule::STOP should be returned if the module wants the pipeline to stop processing this file. 
 
 The file pointer is supplied by the framework and can be used to access both the metadata and the content associated with the file. The file object is managed by the framework and a module must therefore not delete it.  
 
@@ -55,6 +57,15 @@ When the pipeline is being destroyed, the <tt>finalize</tt> function on each mod
 
 <pre>TskModule::Status TSK_MODULE_EXPORT finalize()</pre>
 
+\subsection mod_setup_other Other Methods
+You should also implement methods to return the version, name, and description of the module as follows:
+
+<pre>
+    TSK_MODULE_EXPORT const char *name()
+    TSK_MODULE_EXPORT const char *description()
+    TSK_MODULE_EXPORT const char *version()
+</pre>
+
 \section mod_stuff Doing Stuff in a Module
 Now that we know where to put code in the module, we'll examine what we can do in those places. 
 
@@ -99,4 +110,7 @@ Reporting modules may want to access specific files. To gain access to a file, y
 
 Once you have a file ID, you can get the corresponding TskFile object with the TskFileManager, specifically the TskFileManager.getFile() method. 
 
+\subsection mod_stuff_utilities Utilities
+If you find yourself needing to do some routine data conversions, then check out the TskUtilities class.  It may have methods that are relevant.  If it doesn't, then you may also want to check out the Poco library that the framework depends on.  It may also have some standard methods for doing things instead of you needing to write them from scratch.
+
 */

tsk3/docs/Doxyfile

@@ -1306,7 +1306,7 @@ TAGFILES               =
 # When a file name is specified after GENERATE_TAGFILE, doxygen will create 
 # a tag file that is based on the input files it reads.
 
-GENERATE_TAGFILE       = 
+GENERATE_TAGFILE       = libtsk_doxygen.tag
 
 # If the ALLEXTERNALS tag is set to YES all external classes will be listed 
 # in the class index. If set to NO only the inherited external classes