Skip to content

IBM/ibm-ix-aem-sonarqube-plugin

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

65 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

IBM iX logo

IBM iX Sonar rules for AEM development

Quality Gate Status

Contents

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.

Installation

Manual

  1. Download the latest jar file from the releases section
  2. Place it into your SonarQube installation directory under /extensions/plugins
  3. Restart the SonarQube instance

Sonar Marketplace

(available only in the SonarQube Community version)

  1. Using the SonarQube Administration panel open the Marketplace section
  2. Under the plugins subsection, search for IBM iX AEM Sonar rules and press install
  3. Restart the SonarQube instance

Compatiblity

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.

How to use

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.

Rules

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.

  1. AvoidDeprecatedAdministrative - Avoid administrative access

    • Use Sling Repository login service instead
  2. AvoidFelixAnnotations - Avoid Felix annotations

    • Use OSGi annotations instead of deprecated Felix annotations.
  3. AvoidJcrApi - Avoid JCR Api

    • Prefer to use Sling APIs instead of JCR ones when possible
  4. AvoidOldSlingServletAnnotations - Avoid old Sling Servlet annotations

    • Prefer usage of the newer Sling servlet OSGi DS 1.4 (R7) component property type annotations
  5. AvoidWcmUsePojoClass - Avoid WCMUsePojo class

    • Prefer using Sling models in favor of WCMUsePojo
  6. CloseJcrSession - Close Session class

    • Make sure to always close manually opened Sessions
  7. DefaultInjectionStrategy - Explicitly set defaultInjectionStrategy parameter in Sling models

    • Argument defaultInjectionStrategy should be explicitly set in the Sling model annotation, and in certain cases set to DefaultInjectionStrategy.OPTIONAL
  8. 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.
  9. PostConstructException - Log exceptions in @PostConstruct

    • Wrap all the code in the @PostConstruct method via try-catch in order to catch any runtime exceptions that could occur while adapting the resource/request.
  10. 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.
  11. 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.
  12. 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.
  13. SlingServletResourceOverPath - Prefer binding Sling Servlets with resource type instead of using a path

    • Whenever possible prefer using @SlingServletResourceTypes annotations over @SlingServletPaths.
  14. ThreadSafeObjects - _Avoid member variables which are not thread safe

    • Make sure to never use classes, which are not thread safe, as class member variables.
  15. TryWithResourcesResourceResolver - Use try-with-resources when instantiating ResourceResolver

    • When instantiating a ResourceResolver from the ResourceResolverFactory always use the try-with-resources feature.
  16. UseConstantsForHttpCodes - Use constants for Http response codes

    • Use HttpServletResponse class constants for Http response codes instead of using hardcoded numbers
  17. UseConstantsForLiterals - Use provided constants for String literals

    • Use available constants over String literals or self-declared constants.
  18. UseInjectorSpecificAnnotations - Use injector specific annotations

    • Instead of using the @Inject annotation for every object, it is recommended to use injector-specific annotations
  19. AvoidInjectMocksUsage - Avoid using Mockito InjectMocks in tests

    • Register services into the AEM context instead of using Mockito InjectMocks.
  20. AvoidMockingOsgiComponents - Avoid mocking OSGi component implementations in tests

    • Avoid mocking OSGi component implementations, create a stub implementation or mock the interface instead
  21. 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.
  22. AvoidMockingResourceHandlingObjects - Avoid mocking resource handling objects in tests

    • Avoid mocking ResourceResolver or Session objects as they already come provided in the context
  23. AvoidMockingSlingModels - Avoid mocking Sling models in tests

    • Adapt Sling models from a context resource/request instead of mocking them

License

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