[
https://issues.apache.org/jira/browse/HADOOP-20013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136160#comment-18136160
]
ASF GitHub Bot commented on HADOOP-20013:
-----------------------------------------
joseluisll commented on PR #8891:
URL: https://github.com/apache/hadoop/pull/8891#issuecomment-6561640803
**The SpotBugs -1 is pre-existing trunk debt, not from this patch.**
The only `-1` in the Yetus table is the branch-side row:
> `root in trunk has 80 extant spotbugs warnings`
That row is measured on the base commit (`e66f40daf3c`), before this patch
applies. The patch-side SpotBugs row is `+1`: `the patch passed`. Concretely,
from the artifacts in [build
2](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8891/2/artifact/out/):
- `new-spotbugs-root.xml` contains **0** `BugInstance` elements — this patch
introduces no SpotBugs findings.
- `branch-spotbugs-root-warnings.xml`, `patch-spotbugs-root-warnings.xml`
and `combined-spotbugs-root.xml` each contain 80 instances. Diffing `(type,
class, method, line)` fingerprints between branch and patch gives **0 new, 0
fixed** — the set is identical.
- The only Java file changed here is `TestAnnotationApiClasspath`, and its
module (`hadoop-yarn-server-nodemanager`) reports **0** SpotBugs warnings on
both branch and patch.
- The `root`/`.` module is scheduled only because `LICENSE-binary` and
`NOTICE-binary` sit at the repo root, which pulls in a whole-reactor SpotBugs
run (`modules: C: hadoop-project ... . U: .`).
Where the 80 come from — modules that inherit SpotBugs from the root pom
without wiring in `dev-support/findbugs-exclude-global.xml`:
| module | warnings |
|---|---|
| hadoop-tools/hadoop-distcp | 21 |
| hadoop-tools/hadoop-compat-bench | 12 |
| hadoop-tools/hadoop-federation-balance | 12 |
| hadoop-tools/hadoop-dynamometer/hadoop-dynamometer-infra | 8 |
| hadoop-tools/hadoop-azure-datalake | 7 |
| hadoop-maven-plugins | 7 |
| hadoop-tools/hadoop-dynamometer/hadoop-dynamometer-workload | 7 |
| hadoop-tools/hadoop-archives | 3 |
| hadoop-tools/hadoop-extras | 2 |
| hadoop-tools/hadoop-rumen | 1 |
78 of the 80 are patterns the global filter already lists
(`EI_EXPOSE_REP`/`REP2`, `CT_CONSTRUCTOR_THROW`,
`AT_STALE_THREAD_WRITE_OF_PRIMITIVE`, `SS_SHOULD_BE_STATIC`, ...). They surface
only because those poms never reference the filter that HADOOP-19731 added;
`hadoop-rumen` is the one module here that does have a local filter, and its
single warning is a pattern neither filter lists. The two genuinely uncovered
findings are `ES_COMPARING_STRINGS_WITH_EQ` in `AdlFileSystem.toFileStatuses` —
`entry.name == ""` compares references, so an empty name is not treated as
empty and gets a path set — and `FS_BAD_DATE_FORMAT_FLAG_COMBO` in rumen
`StatePool`, the 12-hour `hh` flag in the `SimpleDateFormat` pattern.
On the rest of the report: the `continuous-integration/jenkins/pr-merge`
"This commit cannot be built" status is the generic error text Yetus emits when
it exits non-zero. The build itself passed — `Build` 3h19m, `unit +1` 773m 46s,
`shadedclient +1` on both branch and patch, javadoc/checkstyle/compile `+1` on
JDK 17 and 21, asflicense clean. This is the same situation as #8753, which
merged with an identical "extant spotbugs warnings" error status.
The base (`e66f40daf3c`) is now 3 commits behind apache trunk, so the 80 is
slightly stale. Happy to rebase to refresh the count, though it won't change
the outcome for this patch.
I'd rather not bundle a ~10-module SpotBugs configuration change into a
two-line dependency exclusion. Plan: file a separate JIRA to add
`excludeFilterFiles` to the modules above and fix the two real findings.
<sub>Drafted with Claude Code; figures verified against the build artifacts
linked above.</sub>
> HADOOP - Remove the duplicate javax.annotation-api from the classpath
> ---------------------------------------------------------------------
>
> Key: HADOOP-20013
> URL: https://issues.apache.org/jira/browse/HADOOP-20013
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: build, common
> Reporter: Jose Luis López
> Assignee: Jose Luis López
> Priority: Major
> Labels: pull-request-available
>
> *Scope*:
> * hadoop-project/pom.xml: on javax-websocket-server-impl, exclude
> javax.annotation:javax.annotation-api, which arrives through
> jetty-annotations. jakarta.annotation-api 1.3.5 already provides the same
> javax.annotation classes.
> * LICENSE-binary and NOTICE-binary: replace
> javax.annotation:javax.annotation-api:1.3.2 with
> jakarta.annotation:jakarta.annotation-api:1.3.5. The jakarta jar is already
> bundled (through jersey-common) but is missing from LICENSE-binary.
> * hadoop-yarn-server-nodemanager: add TestAnnotationApiClasspath, which
> checks that javax/annotation/PostConstruct.class comes from exactly one jar,
> jakarta.annotation-api. With trunk's poms it fails: both jars provide the
> class. It is self-contained and does not depend on HADOOP-19970.
> *Why*: two jars publish the javax.annotation packages, and which one a module
> sees depends on jar order.
> *Impact on Jetty 9*: none. Same classes.
> *Downstream*:
> * hadoop-yarn-server-nodemanager, the only module that declares
> javax-websocket-server-impl: its consumers no longer get javax.annotation-api
> 1.3.2. jakarta.annotation-api 1.3.5 provides the same javax.annotation
> classes.
> * hadoop-client-minicluster: loses its relocated copy of javax.annotation-api
> and keeps the relocated jakarta.annotation-api. Not API.
> * hadoop-client-api, hadoop-client-runtime: unchanged.
> *CI*: touches hadoop-project, so a full build.
> *PR*: https://github.com/apache/hadoop/pull/8891
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
