Analysing Ant using Bark
As an example we show how to use Bark to analyse Ant. Ant is a Java-based build tool, and we apply Bark to version 1.6.5.
First we download the files to analyse. Here we use the binary distribution, that is, a Zip file consisting of the JAR files that make up Ant.
Then we start an Eclipse with the Bark plugin and create a project with a file to hold the analysis results, e.g., "Ant 1.6.5.brk". (The extension .brk is recognised by the Bark plugin.) Then we click on the JAR icon to load the zip file into Bark. We then get this picture.
The diagram shows that Ant contributes to the package hierarchies org and javax and that these contributions each depend on the other. Next, we explain how to read that out of the diagram.
Bark diagrams in 2 minutes
Here's a brief explanation of Bark diagrams:
- A box represents code, such as a Java package, a package hierarchy, or a class.
- Box colours: A green box means Bark found the program element's implementation. A white box means that Bark only found a reference to the program element.
- An arrow represents a dependency of its source on its target, e.g., an arrow from package foo.bar to java.lang.util could means that foo.bar uses parts of java.lang.util.
- Arrow thickness is a rough indication of dependency strength. An arrow with two arrowheads is really a two-way dependency.
External dependencies and hiding
What the above high-level picture of Ant does not show are Ant's external dependencies: What does Ant use that's not part of Ant proper? Clicking on the ghost icon in the menu bar shows these dependencies. Note the strong dependency on package hierarchy java. (We got rid of the project view on the left to save space.)
Things to note:
- Package java and the other external dependencies are grey to indicate that they're normally invisible. We can make them permanently visible; they would then appear in white.
- There are no indicated dependencies between these externals: since they were not parsed by Bark, it has no information about their relationship.
Knowing that the core parts of Ant may be found somewhere under the org package hierarchy, we expand this by clicking on the button marked Expand in the menu palette and then double-click on org.
This shows that Ant contributes web standardised parts in package hierarchies defined by the W3C.
We now make everything except org.apache invisible and then expand that. Inside we further expand org.apache.tools to finally reveal the package org.apache.tools.ant which holds the core of Ant. We also expand org.apache.xml.
It now becomes apparent that Ant is made up of two main parts without direct dependencies:
- Core functionality in org.apache.tools
- XML support in several other packages, including the XML parser Xerces
We reflect this division into parts by making modules with these names. (A module is a collection of related packages that are not necessarily in the same hierarchy.) Then make visible the parts we made invisible before and expand these somewhat to clarify what sub-hierarchies there are.
So far, the structure of Ant looks reasonable.
The Ant core examined
We go back to the package org.apache.tools.ant and ignore the rest. Expanding this hierarchy reveals the core structures of Ant.
We make two observations:
- There are several packages (hierarchies) that are circularly dependent. The existence of such clusters could be an indication of problems with the design.