XCOMMONS-3772: Don't run javac lint checks on generated sources - #1957

Jira URL

https://jira.xwiki.org/browse/XCOMMONS-3772

Changes

Description

The build reports 120 javac lint warnings on machine-generated sources across the 3 repos, and none of them can be
fixed since we don't control the generators. This PR is the xwiki-commons part.

• Adds a xwiki.compiler.xlint property to xwiki-commons-pom, used for javac's -Xlint option, so a module can
  switch off the lint categories it cannot be clean for.
• Stops setting the compiler plugin's showDeprecation option. It passed an unconditional -deprecation to javac,
  which won over any -Xlint:-deprecation a module sets. Deprecation is already part of -Xlint, so this changes
  nothing else (verified below).
• Uses the property in xwiki-commons-repository-model to switch off deprecation and dep-ann, removing that
  module's 8 warnings.

Clarifications

Why the 8 warnings in xwiki-commons-repository-model cannot be fixed in the code: the XSD documents features
(deprecated since 8.0M1) and recommended (deprecated since 16.8.0RC1), and XJC turns that into a javadoc
@deprecated tag without emitting the @Deprecated annotation. That raises 4 dep-ann warnings on the
declarations, and it also raises 4 deprecation warnings, because the generated fluent accessors call the
deprecated getters and are not annotated either:

@Override
public Extension withFeatures(String... values) {
    for (String value : values) { getFeatures().add(value); }   // <- the warning
    return this;
}

withFeatures() exists only to populate the deprecated features element, so there is nothing else it could call,
and features has to stay in the XSD because it is part of the Extension Repository REST format. Had XJC annotated
withFeatures(), javac would have stayed silent, since it does not warn about deprecated use inside deprecated
code.

That module contains no hand-written Java at all, which is why the module-level property is used here. -Xlint is
a per-javac-invocation option and not a per-source-path one, so for modules that mix generated and hand-written
sources the property must not be used, or the hand-written sources would stop being checked too. Those use a
separate maven-compiler-plugin execution instead — see the companion PRs.

This applies to every project inheriting the XWiki parent POM, including xwiki-contrib extensions.

Forum proposal (agreement still pending, hence draft):
https://forum.xwiki.org/t/stop-running-javac-lint-checks-on-generated-code/18828

Companion PRs, which need this one merged first since they rely on the new parent POM:

• xwiki-rendering: XCOMMONS-3772: Don't run javac lint checks on generated sources xwiki-rendering#431
• xwiki-platform: XCOMMONS-3772: Don't run javac lint checks on generated sources xwiki-platform#6333

Screenshots & Video

N/A — no visible result, this is a build configuration change.

Executed Tests

Full reactor build, with the Develocity build cache disabled since otherwise compile is served from cache and
reports no javac warnings at all:

mvn clean install -B -ntp -Plegacy -DskipTests -fae \
    -Ddevelocity.cache.local.enabled=false -Ddevelocity.cache.remote.enabled=false

BUILD SUCCESS, and diffing the warnings against the same build on master:

• javac warnings: 1286 -> 1278, i.e. exactly the 8 generated-source ones, and 0 generated-source warnings remain.
• Every other category is unchanged: unchecked 290, rawtypes 256, this-escape 66, serial 53.
• To confirm dropping showDeprecation loses nothing, xwiki-commons-jakartabridge-servlet (the module with the
  most deprecation warnings) was diffed line by line: the same 88 warnings before and after.

Expected merging strategy

Prefers squash: Yes. No backport needed.

Generated with Claude Code