Skip to content

Exclude generated OpenAPI models from SonarCloud coverage and duplication checks#2002

Merged
thomasc-adyen merged 2 commits into
mainfrom
sonar/exclude-generated-models-coverage
Jul 10, 2026
Merged

Exclude generated OpenAPI models from SonarCloud coverage and duplication checks#2002
thomasc-adyen merged 2 commits into
mainfrom
sonar/exclude-generated-models-coverage

Conversation

@thomasc-adyen

@thomasc-adyen thomasc-adyen commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

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-package JSON.java mapper config) are produced by OpenAPI Generator via adyen-sdk-automation and are not hand-maintained. They were skewing two SonarCloud metrics:

  1. Coverage — diluting the coverage % with untested boilerplate.
  2. Duplication (CPD) — the repetitive generated template triggers huge numbers of duplicated-block warnings. Representative CI run: job 86166267497 logged hundreds of 'Too many duplication references ... Keep only the first 100 references' warnings, all within 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:

<sonar.coverage.exclusions>**/com/adyen/model/*/**</sonar.coverage.exclusions>
<sonar.cpd.exclusions>**/com/adyen/model/*/**</sonar.cpd.exclusions>

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

  • 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

  • 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)
  • All other hand-written library code (Client, Service, Config, httpclient, util, security, notification, builders)

Verification

  • mvn validate passes.
  • mvn help:evaluate -Dexpression=sonar.coverage.exclusions -DforceStdout and -Dexpression=sonar.cpd.exclusions both resolve to **/com/adyen/model/*/**.
  • Confirmed via CI log that all captured duplication warnings originate from com/adyen/model/** (251/251 in the sampled run), none from service/ or hand-written packages.
  • Follow-up: confirm on the next SonarCloud run that coverage % and duplication % reflect only non-generated code.

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)
@thomasc-adyen thomasc-adyen requested a review from a team as a code owner July 9, 2026 16:00

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the pom.xml file to exclude the com.adyen.model package from SonarQube code coverage analysis. There are no review comments, and I have no feedback to provide.

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.
@thomasc-adyen thomasc-adyen changed the title Exclude generated OpenAPI models from SonarCloud coverage metric Exclude generated OpenAPI models from SonarCloud coverage and duplication checks Jul 9, 2026
@sonarqubecloud

sonarqubecloud Bot commented Jul 9, 2026

Copy link
Copy Markdown

@thomasc-adyen thomasc-adyen added this pull request to the merge queue Jul 10, 2026
Merged via the queue into main with commit 037bd8e Jul 10, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants