Exclude generated OpenAPI models from SonarCloud coverage and duplication checks#2002
Merged
Merged
Conversation
Context: SonarCloud coverage was being diluted by the generated data model classes under com/adyen/model/<api>/** (POJOs, getters/setters, equals/hashCode/toString, and the generated per-package JSON.java mapper config). These are produced by OpenAPI Generator from Adyen's OpenAPI specs via adyen-sdk-automation and are not hand-maintained, so their coverage numbers don't reflect meaningful test gaps. Change: Add sonar.coverage.exclusions=**/com/adyen/model/*/** to pom.xml. This only affects the coverage metric and coverage quality gate in SonarCloud; Sonar still analyzes excluded files for bugs, vulnerabilities, and code smells. Why this glob: - Matches files at least one directory below com/adyen/model/, i.e. the generated per-API packages (model/checkout/**, model/management/**, ...). - Does NOT match the top-level com/adyen/model/*.java files, so the hand-written ApiError.java and RequestOptions.java remain in scope (the generated InvalidField.java also stays in scope; a single trivial file, not worth a more complex exclusion pattern). - Path-based and therefore self-maintaining: any new generated API package added under model/ is automatically excluded going forward. What stays fully in scope for coverage: - com/adyen/serializer/** (ByteArraySerializer, DateSerializer, custom Jackson (de)serializers) - com/adyen/terminal/serialization/** (XML/Base64 type adapters) - com/adyen/service/** (generated services were intentionally left in scope for now) - All other hand-written library code (Client, Service, Config, httpclient, util, security, notification, builders)
Context: The generated model classes under com/adyen/model/<api>/** follow a repetitive OpenAPI Generator template (getters/setters, equals/hashCode/ toString, isSet* flags, getExplicitNulls, toJson/fromJson). Sonar's Copy-Paste Detection flags huge numbers of duplicated blocks across these files, e.g. CI run: https://github.com/Adyen/adyen-java-api-library/actions/runs/29031747289/job/86166267497?pr=2002 logged 'Too many duplication references ... Keep only the first 100 references' for hundreds of blocks, all within com/adyen/model/**. This duplication is a byproduct of code generation, not a real maintenance risk, and drowns out genuine duplication signal in hand-written code. Change: Add sonar.cpd.exclusions=**/com/adyen/model/*/** to pom.xml, using the same glob already applied to sonar.coverage.exclusions for consistency. This only removes generated model packages from the duplication metric; Sonar still analyzes them for bugs, vulnerabilities, and code smells, and hand-written code (serializer packages, services, httpclient, etc.) remains fully covered by duplication detection.
|
gcatanese
approved these changes
Jul 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Context
The generated data model classes under
com/adyen/model/<api>/**(POJOs, getters/setters,equals/hashCode/toString,isSet*flags,getExplicitNulls,toJson/fromJson, and the generated per-packageJSON.javamapper config) are produced by OpenAPI Generator via adyen-sdk-automation and are not hand-maintained. They were skewing two SonarCloud metrics:com/adyen/model/**.Both are generation artifacts, not real maintenance/test-gap signals, and they drown out genuine signal from hand-written code.
Change
Add two properties to
pom.xml, using the same glob for consistency:These only affect the coverage and duplication metrics/quality gates; Sonar still analyzes the excluded files for bugs, vulnerabilities, and code smells.
Why this glob
com/adyen/model/, i.e. the generated per-API packages (model/checkout/**,model/management/**, ...).com/adyen/model/*.javafiles, so the hand-writtenApiError.javaandRequestOptions.javaremain in scope (the generatedInvalidField.javaalso stays in scope — a single trivial file, not worth a more complex exclusion pattern).model/is automatically excluded going forward.What stays fully in scope
com/adyen/serializer/**(ByteArraySerializer,DateSerializer, custom Jackson (de)serializers)com/adyen/terminal/serialization/**(XML/Base64 type adapters)com/adyen/service/**(generated services intentionally left in scope for now — no duplication warnings were observed there)Client,Service,Config,httpclient,util,security,notification, builders)Verification
mvn validatepasses.mvn help:evaluate -Dexpression=sonar.coverage.exclusions -DforceStdoutand-Dexpression=sonar.cpd.exclusionsboth resolve to**/com/adyen/model/*/**.com/adyen/model/**(251/251 in the sampled run), none fromservice/or hand-written packages.