SIGN IN SIGN UP

Exclude generated OpenAPI models from SonarCloud coverage metric

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)
T
thomasc committed
965db3db1854a13c239040d611d6c184c26587bc
Parent: 007a6f1