This repository contains free-to-use custom Sonar rules designed specifically for AEM development based on internal IBM iX company guidelines. Adobe Experience Manager (AEM), is a comprehensive content management solution for building websites, mobile apps and forms. The rules can be easily added to SonarQube and used on your AEM project to help improve the overall code quality. Currently, only Java specific rules are in scope of this project.
- Download the latest jar file from the releases section
- Place it into your SonarQube installation directory under
/extensions/plugins - Restart the SonarQube instance
(available only in the SonarQube Community version)
- Using the SonarQube Administration panel open the Marketplace section
- Under the plugins subsection, search for
IBM iX AEM Sonar rulesand press install - Restart the SonarQube instance
The newest version of this plugin (v1.4) only supports SonarQube versions starting from v9.9. If you are using older versions of SonarQube, v1.2 of this plugin can be used for SonarQube v8.9 or newer, although with some known issues that were fixed in the latest version.
Note: since this plugin is written in Java 11, you must make sure not to run the Sonar scanner using an older Java version (usually inside the CI/CD pipeline). This does not impact the code itself that is being analysed (which can use any Java version). This is only relevant if you are using SonarQube v8.9 as all newer versions no longer support running scanner with Java 8.
Rules provided by this plugin should work out-of-the-box. In order to use them, you should add the rules to the quality profile that is used for analysis on your project.
Here you can find the complete list of rules available in this plugin.
More detailed descriptions of the rules can be found when opening the rules in the SonarQube interface.
All the rules can be found in the IBM iX AEM rules repository when using the SonarQube interface.
-
AvoidDeprecatedAdministrative - Avoid administrative access
- Use Sling Repository login service instead
-
AvoidFelixAnnotations - Avoid Felix annotations
- Use OSGi annotations instead of deprecated Felix annotations.
-
AvoidJcrApi - Avoid JCR Api
- Prefer to use Sling APIs instead of JCR ones when possible
-
AvoidOldSlingServletAnnotations - Avoid old Sling Servlet annotations
- Prefer usage of the newer Sling servlet OSGi DS 1.4 (R7) component property type annotations
-
AvoidWcmUsePojoClass - Avoid
WCMUsePojoclass- Prefer using Sling models in favor of WCMUsePojo
-
CloseJcrSession - Close
Sessionclass- Make sure to always close manually opened Sessions
-
DefaultInjectionStrategy - Explicitly set
defaultInjectionStrategyparameter in Sling models- Argument
defaultInjectionStrategyshould be explicitly set in the Sling model annotation, and in certain cases set toDefaultInjectionStrategy.OPTIONAL
- Argument
-
FilterException - Log exceptions in Sling filters
- Catch and log any runtime exceptions your custom code might throw in the filter. That way, we ensure that the filter chain will continue, even if your code is failing.
-
PostConstructException - Log exceptions in
@PostConstruct- Wrap all the code in the
@PostConstructmethod via try-catch in order to catch any runtime exceptions that could occur while adapting the resource/request.
- Wrap all the code in the
-
PreferInjectionOverAdaption - Prefer object injection or utility/factory services over adaption when possible
- When possible, prefer using object injection or utility/factory services instead of adapting the object.
-
SeparateConfigurationClass - Separate OSGi configuration class from the implementation classes
- Put OSGi configuration in a separate class and then use
@Designate(ocd = CustomServiceConfig.class)to load it into an implementation class.
- Put OSGi configuration in a separate class and then use
-
SlingServletException - Log exceptions in Sling servlets and set response codes
- Wrap all the code from a servlet method in a try-catch block and return status code 500 - Internal server error and log any runtime exception.
- Always return the appropriate HTTP status code in a servlet response.
-
SlingServletResourceOverPath - Prefer binding Sling Servlets with resource type instead of using a path
- Whenever possible prefer using
@SlingServletResourceTypesannotations over@SlingServletPaths.
- Whenever possible prefer using
-
ThreadSafeObjects - _Avoid member variables which are not thread safe
- Make sure to never use classes, which are not thread safe, as class member variables.
-
TryWithResourcesResourceResolver - Use
try-with-resourceswhen instantiatingResourceResolver- When instantiating a
ResourceResolverfrom theResourceResolverFactoryalways use thetry-with-resourcesfeature.
- When instantiating a
-
UseConstantsForHttpCodes - Use constants for Http response codes
- Use
HttpServletResponseclass constants for Http response codes instead of using hardcoded numbers
- Use
-
UseConstantsForLiterals - Use provided constants for String literals
- Use available constants over String literals or self-declared constants.
-
UseInjectorSpecificAnnotations - Use injector specific annotations
- Instead of using the
@Injectannotation for every object, it is recommended to use injector-specific annotations
- Instead of using the
-
AvoidInjectMocksUsage - Avoid using Mockito
InjectMocksin tests- Register services into the AEM context instead of using Mockito
InjectMocks.
- Register services into the AEM context instead of using Mockito
-
AvoidMockingOsgiComponents - Avoid mocking OSGi component implementations in tests
- Avoid mocking OSGi component implementations, create a stub implementation or mock the interface instead
-
AvoidMockingRequestAndResponse - Avoid mocking Sling request and response objects in tests
- Instead of mocking Sling request and response objects, use the ones available from the mocked context.
-
AvoidMockingResourceHandlingObjects - Avoid mocking resource handling objects in tests
- Avoid mocking
ResourceResolverorSessionobjects as they already come provided in the context
- Avoid mocking
-
AvoidMockingSlingModels - Avoid mocking Sling models in tests
- Adapt Sling models from a context resource/request instead of mocking them
Copyright 2020-present IBM Corporation
This plugin is licensed under the Apache License, Version 2.0
A part of this plugin contains code from another open source project – AEM-Rules-for-SonarQube
Files that contains reused parts retain the license from the original authors
