Ignoring Modules

Service-Lint supports suppressing rule violations for specific files, directories, or modules using gitignore-style glob patterns. Violations are filtered after all rules run — the rule still executes normally, but matching violations are dropped from the final report.

When to Use

Use module ignoring when a rule legitimately flags a path that should not apply in your project. Common cases:

  • Generated source directories (e.g. /generated/)

  • Vendored or legacy modules that cannot be changed right now

  • Client/stub modules where a rule is not meaningful

  • Modules excluded from a specific compliance requirement

Prefer fixing the violation over suppressing it. Use ignoring only when the violation is a known false positive or an accepted exception.

Configuration Options

Module ignoring can be configured in two places. Both may be used together — patterns from both sources are merged per rule at runtime.

Option 1: Maven Plugin (pom.xml)

Use ignoredModulesByRule inside the service-lint-maven-plugin configuration. Each <ignoreRule> block names a rule and provides one or more glob patterns.

<plugin>
  <groupId>gov.va.mobile.tools</groupId>
  <artifactId>service-lint-maven-plugin</artifactId>
  <configuration>
    <ignoredModulesByRule>
      <ignoreRule>
        <name>SL011</name>
        <ignoredModules>
          <ignoredModule>**/generated/**</ignoredModule>
        </ignoredModules>
      </ignoreRule>
      <ignoreRule>
        <name>SL002</name>
        <ignoredModules>
          <ignoredModule>legacy-client/**</ignoredModule>
          <ignoredModule>**/vendor/**</ignoredModule>
        </ignoredModules>
      </ignoreRule>
    </ignoredModulesByRule>
  </configuration>
</plugin>

Option 2: YAML Config (servicelint-config.yml)

Add an ignoredModules list to any rule entry in your servicelint-config.yml. This option works for both the Maven plugin and the CLI.

rules:
  - name: SL011
    enabled: true
    ignoredModules:
      - "**/generated/**"
      - "some-legacy-module/**"
  - name: SL002
    enabled: true
    ignoredModules:
      - "vendor/**"

Pattern Syntax

Patterns use Java NIO glob syntax and are matched against the file path relative to the project root.

Pattern Matches Example

*

Any characters within a single path segment (no /)

*.xml matches pom.xml but not src/pom.xml

**

Any number of path segments (zero or more)

/generated/ matches any file anywhere under a generated directory

?

Any single character

SL0??.adoc matches SL001.adoc, SL021.adoc

{a,b}

Either alternative

/{test,generated}/ matches paths under test or generated

Patterns are case-insensitive on case-insensitive file systems (macOS, Windows) and case-sensitive on Linux.

Examples

Suppress SL011 warnings for all files under any generated directory
<ignoreRule>
  <name>SL011</name>
  <ignoredModules>
    <ignoredModule>**/generated/**</ignoredModule>
  </ignoredModules>
</ignoreRule>
Suppress SL002 for a specific legacy client module
rules:
  - name: SL002
    ignoredModules:
      - "legacy-openapi-client/**"
Suppress multiple rules for the same path (repeat in both config options or add multiple entries)
rules:
  - name: SL011
    ignoredModules:
      - "vendor/**"
  - name: SL006
    ignoredModules:
      - "vendor/**"

How It Works

Violations are filtered after all rules have run. The rule receives no knowledge of ignore patterns and executes as normal. The filter:

  1. Resolves the violation’s file path relative to the project root.

  2. For each pattern configured for that rule, checks whether the relative path matches using java.nio.file.PathMatcher with glob: syntax.

  3. If any pattern matches, the violation is dropped.

Rules that produce violations with no associated file path (e.g. version-check rules) are not affected by module ignoring.

See Also