slachiewicz commented on PR #587:
URL:
https://github.com/apache/maven-apache-parent/pull/587#issuecomment-5399718310
I measured what the 0.16.1 → 0.18 move actually changes, using
`maven-parent` as the subject because it is where a `rat-check` execution is
actually bound. Two findings, and they point in opposite directions.
## The version bump is not behaviour-neutral, even with configuration
untouched
Same POM, same `<excludes>`, only the plugin version changed:
| Plugin version | Files scanned | Unapproved |
|---|---|---|
| 0.16.1 | 13 | 0 |
| 0.18 | 28 | 0 |
0.18 scans 15 files that 0.16.1 skipped, because its default exclusion set
changed. Everything extra was licensed here, so `maven-parent` stays green —
but a project holding an unlicensed file that 0.16.1 happened to skip will fail
on the bump for a reason unrelated to this PR. Worth a release-note sentence so
maintainers check rather than assume.
This does not argue against merging. `apache-parent` declares rat only in
`pluginManagement`, with no `<execution>` and no `<configuration>`, so nothing
here executes rat and nothing changes for a child until it bumps its own parent
version.
## Do not "fix" the deprecation warning by renaming the element
0.18 warns `Use of deprecated option 'exclude'`. The obvious response is to
rename `<excludes>` to `<inputExcludes>`. That is not a rename. Measured on
`maven-parent` under 0.18, with the same ten patterns and nothing else altered:
| Configuration | Files scanned | Result |
|---|---|---|
| `<excludes>` (deprecated) | 28 | 0 unapproved, BUILD SUCCESS |
| `<inputExcludes>` (renamed) | 4 | 0 unapproved, BUILD SUCCESS |
The 24 files that stop being checked are every file under `docs/` (17),
`maven-extensions/`, `maven-plugins/`, `maven-shared-components/` and
`maven-skins/` (2 each) — whole modules. The new option routes through the
current engine, where `excludeSubProjects` (default `true`) takes effect; the
deprecated one does not reach it.
The failure mode is the dangerous one: the license check stops covering most
of the tree and still reports success. Nothing in the build output says
coverage collapsed.
apache/maven#12402 shows the same trap from the other side — a
hand-migration there dropped `.mvn/**` and rewrote `dir/**` as `dir`, producing
3298 unapproved files. That one at least went red.
## Suggested handling
- Merge this as-is. Old-style `<excludes>` keeps working under 0.18 with a
warning, so no downstream project needs to change anything on the parent bump.
- In the release notes: rat 0.18 requires JDK 17 to execute (`major version:
61`; 0.17 is the last Java 8 line at `major version: 52` and can be pinned
through `version.apache-rat-plugin`, carrying `commons-lang3` 3.20.0 with it),
and 0.18 scans a slightly wider default set.
- Treat the `inputExclude` migration as separate, per project, and validate
it by diffing RAT's scanned-file *list* before and after. The counter totals do
not reveal this: both configurations above report `0 unapproved`.
For evidence across the core projects before this lands,
apache/maven-parent#598 puts 0.18 behind a temporary `[17,)`-activated profile
so the JDK 8 CI cell keeps 0.16.1.
One procedural note: the comment above suggesting this is a duplicate of
#574 has the direction reversed. #574 is closed and unmerged — closed with
"suppressed by #587". Closing this one would leave the estate on 0.16.1.
Commands to replay: `javap -v org/apache/rat/plugin/RatCheckMojo.class` from
the 0.17 and 0.18 plugin jars; `mvn -N
org.apache.rat:apache-rat-plugin:{0.16.1,0.18}:check` on `maven-parent` master,
comparing `target/rat.txt`.
*This comment was created with AI assistance.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
