Configuration File Format

This page is deprecated and will go away. I got replaced by the official documentation of Degraph.

Except for very basic experiments you'll want to specify a configuration file using the -f command line argument. This page describes the format of the configuration file.

Example File

We'll go through the different parts of the configuration file by examining an example, which is also included in the distribution of Degraph

output = example.graphml
classpath = .
exclude = java*
part = {
    de.schauderhaft.*.(*).**
}
lib = {
de.schauderhaft.(*).**
**(scala)**
*.(*).**
}
internalExternal = {
    internal de.schauderhaft.**
    external **
}

##Simple Properties## You can provide simple properties for the path to analyze, the name of the file to generate, classes to include or exclude using the syntax

<property>=<value>

Available properties are:

• output
• classpath
• exclude
• include

Each property has to stand on its own line.

##Slicing## You can specify an arbitrary number of slicings through your code base. A slicing is a grouping of classes that in some sense belong to each other. Examples might be:

• classes belonging to the same library, like hibernate, log4j and so on.
• classes belonging to the same module, like shoppingcart, authentication, fullfillment.
• classes belonging to the same layer, like UI, domain, persistence, restapi
• classes belonging to your code vs. external stuff: internal, external

For each slicing you want to apply you add a section like this to the configuration:

<slicinglabel> = {
<list of patterns>
}

Note that the opening { has to be on the same line as the label and = sign while the closing } has to be on its own line. Patterns come in two and a half flavors:

Named patterns look like this:

<name> <pattern>

Every class that is matched by the pattern is part of the slice given by the name. So a pattern of

mine de.schauderhaft.** 

will put all classes with a full qualified name starting with de.schauderhaft. in a slice named mine.

Simple patterns look like this:

<pattern>

or

<prefix>(<naming part>)<suffix>

A class matched by this pattern will get added to the slice given by the full <pattern> (first case) or by the <naming part> in the second case.

For example this pattern

*.(*).** 

will put all classes from org.junit. in the slice junit and all the stuff from org.hibernate. in the slice hibernate.

All patterns in a slicing definition (i.e. between {and }) will get tried in order for each class until a match is found. That match defines the slice used for the class.

The pattern matching syntax

Pattern matching in the definition of slices uses an Ant like syntax for specifying full qualified class names. With * standing in for an arbitrary number (0-n) of arbitrary characters, but no dots. ** matches and arbitrary number (0-n) of arbitrary characters, including dots.