jQAssistant 1.4.0 and SonarQube Plugin released
Today we’re proud to announce two new releases: one coming from the jQAssistant team itself and the other from the community. Let’s start with the latter!
SonarQube 5/6 Plugin
The SonarQube plugin for jQAssistant got an refurbishment and now supports SonarQube 5 and 6! It allows publishing the results of jQAssistant analysis to SonarQube and create issues for detected violations.
Our appreciation goes to msg for the efforts they spent into getting this done and also providing support for maintaining the plugin in the future – thanks a lot! Please read the official announcement, installation and usage instructions can be found on GitHub.
The Spring plugin provides rules for applications based on the Spring Framework and Spring Boot. Beside concepts that add labels like „Controller“, „Service“ or „Repository“ it also comes with constraints that enforce best practices like allowed/disallowed dependencies or constructor injection.
The rules can be activated easily by using the pre-defined groups „spring-boot:Default“ and „spring-boot:Strict“, e.g. by either including the group into your own rules…
[[spring:Default]] [role=group,includesGroups="spring-boot:Strict"] == Spring Framework
…or activating the group in the Maven plugin (tutorial)…
<plugin> <groupId>com.buschmais.jqassistant</groupId> <artifactId>jqassistant-maven-plugin</artifactId> <version>1.4.0</version> <executions> <execution> <id>default-cli</id> <goals> <goal>scan</goal> <goal>analyze</goal> </goals> <configuration> <groups> <group>spring-boot:Strict</group> <!-- or "spring-boot:Default" for more relaxed checks --> </groups> </configuration> </execution> </executions> </plugin>
or referencing the group as parameter for the command line utility:
jqassistant scan -f my-project/ jqassistant analyze -groups spring-boot:Strict
Our appreciation goes to Oliver Gierke (Pivotal) who helped us defining, implementing and testing the rules – thanks a lot!
Maintenance of test code is an important part of development and sometimes harder than working on the application code itself. Therefore jQAssistant now provides support for JUnit 5 that allows you creating rule based on concepts like “ junit5:TestMethod“, „junit5:ParameterizedTestMethod“ or „junit5:RepeatedTestMethod“. For a list of all rules refer to the plugin documentation.
Until now jQAssistant relied on Neo4j v2.x and it was more than about time for an upgrade… From now on the jQAssistant Maven plugin automatically runs Neo4j 3.4 if Java 8 or later is found. For users who are still forced to work with Java 7 there’s an automatic fall back to Neo4j v2.x.
Consequently the command line utility is now available in two different distributions – one with embedded Neo4j 3.x (requires Java 8) and one with Neo4j 2.x.
There’s one more thing… We’ve also embedded the latest release of Awesome Procedures On Cypher for Neo4j 3.x providing lots of powerful functions and procedures.
For those using a CI server (anybody seriously out there who does not?) jQAssistant now writes analysis results as JUnit reports which can be evaluated by Jenkins & Co. Every executed rule will be reported as test case in one of the states SUCCESS, FAILURE or ERROR. This allows breaking a build if necessary and create trends. So if you’re building a Maven project you can simply activate that feature by letting your CI server scan the directory target/jqassistant/report/junit/*.xml for JUnit reports in addition to target/surefire-reports/*.xml.
The results of concepts or constraints may be reported as CSV files by selecting the report type „csv:
[[test:TestMethodsPerClass]] [source,cypher,role=concept,requiresConcepts="junit4:TestMethod",reportType="csv"] ---- MATCH (artifact:Artifact)-[:CONTAINS]->(testClass:Class)-[:DECLARES]->(testMethod:Test:Method) RETURN artifact.fqn as Artifact, testClass.fqn as TestClass, count(testMethod) as TestMethods ----
…or as XML rule:
<concept id="test:TestMethodsPerClass"> <description>Test Concept.</description> <cypher><![CDATA[ MATCH (artifact:Artifact)-[:CONTAINS]->(testClass:Class)-[:DECLARES]->(testMethod:Test:Method) RETURN artifact.fqn as Artifact, testClass.fqn as TestClass, count(testMethod) as TestMethods ]]></cypher> <report type="csv"/> </concept>
The CSV file will be created in the report directory as csv/test_TestMethodsPerClass.csv.
The EJB plugin provides a new concept „Ejb:Schedule“ for labeling scheduled methods as well as a constraint „ejb3:ScheduleMethodInEjbContext“ ensuring that these are actually located in EJBs (thanks to Sascha Grebe for the PR).
There’s are also changes to the Java plugin: it has been updated to scan newer Java bytecode versions (Java 9/10). It also creates nodes for variables defined in methods: „(:Method)-[:DECLARES]->(:Variable)“.
Under the hood there have been some activities to extend and refactor existing plugin APIs to enable interesting features in the very near future: Asciidoc files containing rules will be rendered to HTML including rule results as tables or UML diagrams (see Asciidoc Report Plugin). Furthermore it will be possible to create rules in other languages like PlantUML component diagrams, e.g. for defining allowed dependencies between layers or business modules (see PlantUML Rule Plugin).
Release Notes and Distributions
The release notes are available here.