jQAssistant 1.3.0 released

A new release of jQAssistant is available and it comes with some interesting new features! Read about them in this release announcement and for keeping you curious there’s also a preview on what to expect from jQAssistant development in the near future.

JSON plugin

The new JSON scanner plugin picks up *.json files and stores them in a generic represenation in the graph database. For a file „/indy.json“ with the content…

{
  "firstName" : "Indiana ",
  "lastName" : "Name"
}

…the values of all attributes can be gathered using the following Cypher query:

MATCH
  (f:Json:File)-[:CONTAINS]->(object:Json:Object),
  (root)-[:HAS_KEY]->(key:Json:Key)-[:HAS_VALUE]->(value:Json:Value:Scalar)
WHERE
  f.fileName="/indy.json"
RETURN
  f.fileName, key.name, value.value

For more information on the structure refer to the plugin documentation.

Support for Remote Neo4j Servers

Until now jQAssistant users had to use the Neo4j community edition which comes embedded with the command line tool or the Maven plugin. There’s now additional support for connecting to existing Neo4j 3.x instances using the bolt protocol. Therefore the command line utility supports new parameters:

bin/jqassistant.sh scan -f myApplication.war -storeUri bolt://localhost:7687 -storeUsername=neo4j -storePassword=secret

For the Maven plugin a store section is available in the plugin configuration:

<plugin>
  <groupId>com.buschmais.jqassistant</groupId>
  <artifactId>jqassistant-maven-plugin</artifactId>
  <version>1.3.0</version>
  <configuration>
    <store>
      <uri>bolt://localhost:7687</uri>
      <username>neo4j</username>
      <password>secret</password>
    </store>
  </configuration>
</plugin>

There’s no difference in the behavior of jQAssistant in using the embedded or a remote Neo4j instance but scanning of course is a bit slower (about 2-3 times).

This new feature enables setting up a job on your continuous integration server to scan your application on a regular base and make the data available to developers, architects, QA engineers such that they can explore the code structures or gather metrics using cypher queries.

Rule Severities

The default severities of rules have been raised: If not specified otherwise concepts will now use „MINOR“ (before „INFO“) and constraints „MAJOR“ (before: „MINOR“). It is also possible to define default severities for groups, concepts and constraints, e.g. for the Maven plugin:

<plugin>
  <groupId>com.buschmais.jqassistant</groupId>
  <artifactId>jqassistant-maven-plugin</artifactId>
  <version>1.3.0</version>
  <configuration>
    <rule>
      <!-- values from older jQAssistant releases -->
      <defaultConceptSeverity>INFO</defaultConceptSeverity>
      <defaultConstraintSeverity>MINOR</defaultConstraintSeverity>
    </rule>
  </configuration>
</plugin>

WarnOnSeverity and FailOnSeverity

These two new options have been introduced to allow more fine grained control on printing warnings on the console or breaking a build:

<plugin>
  <groupId>com.buschmais.jqassistant</groupId>
  <artifactId>jqassistant-maven-plugin</artifactId>
  <version>1.3.0</version>
  <configuration>
    <rule>
      <warnOnSeverity>INFO</warnOnSeverity>
      <failOnSeverity>CRITICAL</failOnSeverity>
    </rule>
  </configuration>
</plugin>

The options „failOnViolations“ and „severity“ have been deprecated and will be removed in future releases.

Release Notes, Documentation and Download

For a full list of changes refer to the release notes, the full documentation is available here.

The command line utility can be downloaded as ZIP archive, for upgrading the Maven plugin just change the plugin version from 1.2.0 to 1.3.0.

What’s up next?

There are cool ideas in the pipeline and here’s what to expect in the next release:

Asciidoc as executable documentation and report

Since the first official release jQAssistant can evaluate rules which are embedded in Asciidoc files. It’s a core feature and the idea behind is to provide an approach for executable design and architecture documentation. In the near future it will be possible to render these documents directly to HTML or PDF documents including the results of executed rules. Thus every build which includes a run of jQAssistant will provide information about the currently defined rules and the conformity of the system in a human readable representation in just one single place.

Parameter sets

jQAssistant already provides support for parameterized rules, i.e. concepts and constraints may define parameters. There will be an option to define parameter sets, e.g. as Asciidoc tables where each row will be applied for executing a rule.

PlantUML rules

At this time rules can be expressed as Cypher queries or scripting languages (e.g. Groovy or JavaScript). There are use cases (especially in the case of architectural concepts) where it is more convenient and intuitive to use diagrams, e.g. for defining components and their allowed dependencies. There will be initial support for this scenario using PlantUML diagrams.

Last but not least two other releases will be announced soon: an update of the SonarQube plugin and a brand new Spring plugin providing rules for ensuring clean design and architecture of Spring Boot applications.

Stay tuned!