As we all know, SonarQube is a great tool that helps us increase quality of our codebase. However, it does apply mainly to general Java issues. As we know, we can hurt ourselves much more doing AEM. Adobe Experience Manager is a comprehensive content management platform solution for building websites, mobile apps and forms. This tool is intended to find common bugs and bad smells specific for AEM development. Documentation of each rule is available from SonarQube interface after plugin installation.
Each release has its own prerequisites section, for more information please check releases page.
Custom Dockerfile
Following Dockerfile uses official Sonarqube 7.9 image and download AEM Rules 1.0-RC2 to plugin directory.
FROM sonarqube:7.9-community AS aemrulesqube79
RUN curl -Lk -o $SONARQUBE_HOME/extensions/plugins/aemrules-1.0-RC2.jar https://github.com/wttech/AEM-Rules-for-SonarQube/releases/download/v1.0-RC2/aemrules-1.0-RC2.jar
Community image
This is already prepared solution thanks to @ahmed-musallam.
docker run --rm -p 9000:9000 ahmedmusallam/sonarqube-aem:latest
This solution is for those who would like to start testing theirs code within aem rules and sonarqube. It contains SonarQube v 7.7, aem rules v 0.11 and predefined quality gates. If you would like to participate in our Aem Rules development, please refer to wiki page to get into.
Go to your SonarQube instance administration console and open Update Center. Find AEM Rules for SonarQube plugin and click install!
aemrules-x.y.jar
or build AEM Rules for SonarQube plugin.sonarqube/extensions/plugins
directory.Use of the plugin does not differ much from regular SonarQube analysis. However, as rules are often tied to a certain AEM version and its components (Felix, Sling), we've introduced the aemVersion
analysis property.
Each rule defines supported AEM version or version range. Most of the rules are universal. By providing the AEM version parameter, you can instruct the Sonar Runner to only use only a subset of rules applicable to a particular AEM version. When the parameter is not provided then a default AEM version is used (currently 6.4)
When running analysis, pass sonarRunner.aemVersion
property with your AEM version. The format is as follows:
sonarRunner.aemVersion=<MAJOR_VERSION>.<MINOR_VERSION>
Runing with Maven
mvn sonar:sonar -DsonarRunner.aemVersion=6.4
Runing with Gradle (See Gradle AEM Plugin)
gradlew sonarQube -DsonarRunner.aemVersion=6.4
Below you will find descriptions of all rules available in AEM Rules for SonarQube plugin.
AEM-1 Use predefined constant in annotation instead of hardcoded value.
AEM-2 Use predefined constant instead of hardcoded value.
AEM-5 getContentResource()
is not null checked
getContentResource()
. It is possible to get a null if a jcr:content node does not exist in the repository.AEM-8 Prefer cleaner @SlingServlet
annotation.
@SlingServlet
annotation over @Properties
approach. Do not mix up both approaches.AEM-15 Usage of synchronized
keyword should be avoided if possible.
synchronized
keyword should be avoided if possible. Check if using synchronized
can be replaced with more sophisticated solution.AEM-17 No mutator methods invoked on ModifiableValueMap
ModifiableValueMap
should be replaced by ValueMap
if no mutator methods are invoked.AEM-19 Implicit search strategy used in Sling Query
SearchStrategy
can have negative performance impact if mismatched.
Therefore developer should always make informed decision and define strategy explicitly.HTL-1 Wrong placement of the HTL Attribute.
HTL-2 HTL Templates should be placed in separate files.
HTL-3 Use Explicit Names in Loops
data-sly-list
and data-sly-repeat
blocks.
Try to avoid them and use explicit names clarifying the role of the objects instead.HTL-4 Name and re-use Repeating Conditions
HTL-5 Usage of HTML comments should be avoided if possible
HTL-6 HTL automatically recognises the context for HTML output
HTL-7 Style and script tags display context definition is mandatory
HTL-8 Event attribute attributes must have display context defined
HTL-9 Inline styles must have display context defined
HTL-10 Use sly tags over redundant markup.
HTL-11 Use existing HTML elements instead of adding extra sly tags.
HTL-12 Use the most restrictive HTL context possible.
HTL-13 Avoid using 'unsafe' display context.
HTL-14 HTL expressions in HTML comments should have defined context.
HTL-15 Use Camel Case in identifiers:
AEM-3 Non-thread safe object used as a field of Servlet / Filter etc.
Servlet
or Filter
. Rule checks for the occurrence of any instance or static fields of following types:org.apache.sling.api.resource.ResourceResolver
javax.jcr.Session
com.day.cq.wcm.api.PageManager
com.day.cq.wcm.api.components.ComponentManager
com.day.cq.wcm.api.designer.Designer
com.day.cq.dam.api.AssetManager
com.day.cq.tagging.TagManager
com.day.cq.security.UserManager
org.apache.jackrabbit.api.security.user.Authorizable
org.apache.jackrabbit.api.security.user.User
org.apache.jackrabbit.api.security.user.UserManager
AEM-6 ResourceResolver should be closed in finally block.
close
method. It is very important to call the close
method once the resource resolver is not used any more to ensure any system resources are properly clean up.AEM-7 Session should be logged out in finally block.
javax.jcr.Session
should be logged out after it is no longer needed. The logout
method releases all resources associated with Session
.AEM-11 Do not use deprecated administrative access methods
ResourceResolverFactory.getAdministrativeResourceResolver
and SlingRepository.loginAdministrative
has been deprecated. Use ResourceResolverFactory.getServiceResourceResolver
or SlingRepository.loginService
respectively.DefaultInjectionStrategy
@Optional
annotation is redundant, when defaultInjectionStrategy
is OPTIONAL
.Release notes for each version can be found in releases section.
Copyright 2015-2016 Wunderman Thompson Technology
Licensed under the Apache License, Version 2.0
Technical support can be made available if needed. Please contact us for more details.
We can: