+ :PROPERTIES:
+ :ID: 2ad2889e-6c95-4662-b3f4-2c341fc74522
+ :END:
+JavaInspect can be controlled in 2 different ways:
++ [[id:acf1896a-74b4-4914-acf6-a77075e07f25][as standalone commandline utility]]
++ [[id:bbeeffc8-3767-440d-8d93-ec9124dd60ee][as embedded Java library via Java API]]
+
+** Usage as commandline utility
+ :PROPERTIES:
+ :ID: acf1896a-74b4-4914-acf6-a77075e07f25
+ :END:
+*** Available commandline arguments
+#+BEGIN_VERSE
+-j (existing files)...
+ JAR file(s) to render.
+
+-c (existing directories)...
+ Classpath directories
+
+-n (string)
+ Graph name. (default: "graph")
+
+--debug
+ Show debug info.
+
+-h, --help
+ Show commandline usage help.
+
+-k
+ Keep dot file.
+
+-ho
+ Hide orphaned classes.
+
+-w (one to many strings)...
+ Whitelist glob(s).
+
+-b (one to many strings)...
+ Blacklist glob(s).
+
+-r (one to many strings)...
+ root class(es).
+
+-d (existing directory)
+ Target directory. Default is current directory.
+
+-t (options: png, svg)
+ Target image type. Default is: svg.
+#+END_VERSE
+*** Specifying classes to render
+Normal Java application has immense complexity. In addition to code
+that was directly written by particular project developers, lots of
+functionality is typically added as frameworks or libraries to the
+project. In addition there is significant Java standard library.
+
+Because JavaInspect uses reflection, it does not easily distinguish
+between those. In normal situation you would rather want to visualize
+only code that was developed specifically for your project and leave
+frameworks like Spring etc. out. If you visualize all classes that are
+possibly reachable from you project, you will easily get huge and
+incomprehensible graph.
+
+JavaInspect can digest compiled Java classes in 2 modes:
+1. Provide list of Jar files. Use *-j* option.
+2. Provide list of filesystem directories that can be used as
+ classpath root. Use *-c* option.
+
+Currently JavaInspect uses following algorithm to add classes to
+rendered graph:
+
+- All classes that were found in Jar files are added to graph by default.
+- None of the classes that were found in filesystem directories are
+ added to the graph by default (unless explicitly referenced). (TODO:
+ for consistency it would be better to add them too by default)
+- If whitelist is specified (*-w* option) everything that is not
+ matched by whitelist pattern(s) will be removed from the graph.
+- If blacklist is specified (*-b* option) everything that is matched
+ by blacklist pattern(s) will be removed from the graph.
+- Root classes can be specified using *-r* option. Root classes will
+ be added to the graph. JavaInspect will then try to recursively
+ discover all classes that were referenced by root class and add
+ those also to the graph.
+
+** Usage via Java API
+ :PROPERTIES:
+ :ID: bbeeffc8-3767-440d-8d93-ec9124dd60ee
+ :END:
+Requires that classes to be visualised are available in the classpath.
+
+To get JavaInspect into same classpath with your projecs I so far came
+up with 2 solutions:
+
+1. Add JavaInspect library in your project as a dependency.
+
+2. Create new Java project for the purpose visualizing your other
+ projects and include JavaInspect and your projecs binary artifacts
+ (Jar's) into new project classpath. Built binary Jar's (with no
+ source code) are sufficient because JavaInspect operates via
+ reflection.
+
+Simple Java based control/configuration code needs to be written for
+each project. I usually put such code into directories devoted for