slachiewicz opened a new pull request, #307:
URL: https://github.com/apache/maven-gh-actions-shared/pull/307
Offers an opt-in step in `fail-fast-build` that compiles a project against
the Maven version it
declares in `<prerequisites>`, so the declared minimum is actually tested.
### Why
`<mavenVersion>` is the only thing that expresses a project's Maven API
baseline, and nothing
ties it to `<prerequisites>`. `requireMavenVersion` constrains the Maven
that *builds* the
project, not the API level it compiles against, so the two drift silently.
They already have. Across the plugin estate, **45 POMs** declare a
`<prerequisites><maven>` that
differs from the `<mavenVersion>` they build against — commonly `3.6.3`
against `3.9.x`.
apache/maven-dependency-plugin#1682 is what this would have caught:
`RenderDependenciesMojo` uses
`MojoExecutionException(Throwable)`, added in Maven 3.9.0 and absent from
the declared 3.6.3
baseline. The reference is in released bytecode for 3.9.0, 3.10.0 and
3.11.0, so that branch
raises `NoSuchMethodError` on the version the plugin claims to support.
### What it adds
Three inputs, all optional. `ff-baseline-maven` defaults to empty, so
**nothing changes for a
project that does not opt in**:
| input | default | purpose |
|---|---|---|
| `ff-baseline-maven` | `''` | the declared minimum, e.g. `3.6.3`; empty
disables the check |
| `ff-baseline-property` | `mavenVersion` | property to override — 86 POMs
use `mavenVersion`, 19 use `maven.version` |
| `ff-baseline-goal` | `clean test-compile` | what to run |
Opting in:
```yaml
with:
ff-baseline-maven: '3.6.3'
```
Skipped when `maven4-build` is true — a Maven 4 only project has no older
baseline to honour.
### Two details that are load-bearing
**The goal must start with `clean`.** `target/` is warm from the build and
site steps above.
Without `clean` the compiler reports `Nothing to compile - all classes are
up to date` and the
step goes green without compiling a thing. Verified locally against
maven-dependency-plugin:
```
$ mvn -DmavenVersion=3.6.3 test-compile # warm target/
[INFO] Nothing to compile - all classes are up to date.
[INFO] BUILD SUCCESS <-- false green
$ mvn -DmavenVersion=3.6.3 clean test-compile
[ERROR] RenderDependenciesMojo.java:[241,50] incompatible types:
java.io.IOException cannot be converted to java.lang.String
```
**Placement is after `Upload Maven Site`,** because that `clean` would
otherwise discard
`target/staging` before it is uploaded.
`test-compile` rather than `verify` is deliberate: API drift is a
compile-time property, so both
source roots compiling is sufficient, at a fraction of the cost of a second
test run.
### Testing
`maven-verify-test.yml` gains two cases: `verify-7` exercises the check,
`verify-8` asserts it is
skipped for a `maven4-build` project.
### Not included
Consumer documentation lives in `README.md` on `main`, so that is a separate
PR — happy to open it
if the approach here is acceptable.
Draft while the shape is up for discussion. In particular,
`ff-baseline-property` exists only
because the estate is not consistent; if the preference is to require
`mavenVersion` and fix the
19 outliers instead, the input can go.
<sub>Drafted with Claude — please verify</sub>
--
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]