Customize the JArchitect Analysis

JArchitect Documentation

  • Docs
  • Customize the JArchitect Analysis

JArchitect Analysis

Introduction

JArchitect gathers data from a code base. This includes quality code metrics, componentization/architecture/dependencies, evolution and changes, state mutability, usage of tier code and more. The amount of data gathered is proportional to the size of the code base and can become pretty big in case of a large application analyzed. JArchitect added value lies in its capabilities to let the user browse readily this huge amount of data. This way developers and architects can know precisely what’s really happening inside their shop and can take decisions based on real facts, not based on intuition and rumor. There are 2 distinct scenarios to browse data:

  • Through a report: JArchitect analysis process can be integrated into a build process and can produce a customizable HTML report each time the analysis is run. The is suited to produce daily dash-boards useful for every members of the team, even non-technical ones.

  • Through the interactive UI: The interactive UI comes with several panels to visualize and query interactively information about the code base. Interactive UI users are architects and developers that need to dig into details of the code base at any time during development time.
Let's expose here some details about how to integrate JArchitect into a build process and customize analysis. Let's first explain how JArchitect can provide useful warnings about the health of a build process.

Go to top

Warnings about the health of the build process

These warnings can be found:

  • in XML format in the file $AnalysisResultDir$\InfoWarnings.xml,
  • in the report section JArchitect information and warnings,
  • in the panel JArchitect Error List in the interactive UI.



What we mean by the health of the build process is some details that can reveal potential flaws.

In the Error List panel of the interactive UI you have the possibility to deactivate false warnings to avoid being warned again and again during future analysis.

Go to top

Running an Analysis with JArchitect.Console.exe

JArchitect comes with 2 executables:

  • JArchitect.Console.exe to run an analysis.
  • VisualJArchitect.exe a standalone executable to run interactive UI.

JArchitect.Console.exe is a classic console executable that takes command line arguments. The only required input is an absolute path to the JArchitect project file (extension .jdproj) that defines the code base to be analyzed. Several command line arguments can be provided and they are listed here: JArchitect.Console.exe. Basically these arguments will let you override the output folder where data produced by the analysis will be persisted and provide a XSL sheet to customize the report. A simple exec command is needed to integrate JArchitect.Console.exe into your build process. More documentation is available concerning the integration of JArchitect with different build technologies.

Go to top

Analysis Options

To handle real-world scenarios, there are several analysis options. Options can be tuned through the VisualJArchitect > Project Properties panel. Options are then persisted into the JArchitect project file (extension .jdproj) and can be harnessed at analysis time.

The first option is the ability to choose between absolute and relative paths to folders where analyzed projects are stored. If you choose the option value relative path, paths are relative to the folder where the JArchitect project is stored. This option is useful when the JArchitect analysis is performed on several machines (build servers, developer machines…) where the root folder of the whole development shop can vary.



In the VisualJArchitect > Project Properties > Analysis sub-panel, you’ll find 2 interesting options beside the project name and output folder.



The Baseline for Comparison option lets define the previous analysis result on which to compare the current analysis performed (or the current analysis result loaded in interactive UI). This is useful if you’ve defined some CQLinq rules about evolution of your code base like for example, get all new or refactored methods (More information about this can be found here: Reporting Code Diff) : 
warnif count > 0 
from m in Application.Methods where
  (m.WasAdded() || m.CodeWasChanged()) 
select new { m, m.PercentageCoverage }
Basically, here (m.WasAdded() || m.CodeWasChanged()) means was added or refactored compare to the baseline. The baseline for comparison can be
  • a particular result (like the analysis of the last release we’ve made),
  • a result made N days ago
  • or the last analysis result available.

Below, you'll find details to detect CQLinq result violations in the report.

The Trend Metrics Log option lets specify the frequency of logs, like at most once a day or a week

The Code Coverage option lets specify the Cobertura coverage file(s) from which JArchitect will gather test coverage statistics. More details about how to obtain these coverage files can be found in the JArchitect documentation Coverage FAQ.

The Plugins option lets specify the other java tools analysis file(s) from which JArchitect will gather data. More details about how to import plugins files can be found in the JArchitect documentation Plugins FAQ.

Go to top