slachiewicz commented on issue #12676: URL: https://github.com/apache/maven/issues/12676#issuecomment-5181247303
## Jenkins rerun complete — 90 of 93 finished, 85 green All `master` and `3.x` jobs in `maven-box` were rerun after the shared-library fixes. Five did not come back green; here is what each one is, since only one of them is actually caused by this work. | Job | Cause | Ours? | |---|---|---| | maven-resources-plugin/master #175 | UNSTABLE — `MRESOURCES-131` FAILED, 26 ITs passed | No, and apache/maven-resources-plugin#500 fixes it. The IT has been failing since 4.0.0-rc-5 | | maven-shared-utils/master #191 | UNSTABLE — also unstable in #188 and #189, before the rerun | No, pre-existing | | maven-surefire/master #485 | `E2ETest.endToEndTest` failed. No wrapper or version-resolution errors in the log; #484 was green yesterday | No, unrelated to the wrapper change | | maven-reporting-impl/maven-reporting-impl-3.x #5 | `Could not find artifact org.apache.maven.doxia:doxia-sink-api:jar:1.12.0-SNAPSHOT` | No, a stale SNAPSHOT dependency | | maven-reporting-api/maven-reporting-api-3.x #4 | apache-rat: `Too many files with unapproved license: 1` | **Yes — see below** | ### The RAT failure is a side effect of provisioning the wrapper Since apache/maven-jenkins-lib#22, every build generates the Maven wrapper into the workspace before building. That writes three files, and they are not equal in the eyes of apache-rat: - `mvnw` — carries an ASF licence header - `mvnw.cmd` — carries an ASF licence header - `.mvn/wrapper/maven-wrapper.properties` — **no header**, just `wrapperVersion` / `distributionType` / `distributionUrl` Exactly one unlicensed file, which matches the count RAT reports. It only fails where the RAT configuration does not exclude it. `maven-reporting-api-3.x` inherits `maven-shared-components:34`, which predates the wrapper; the same repository's `master` is on `maven-shared-components:49` and passes. So this will affect old maintenance branches on old parents, and leave modern branches alone — 1 job out of 93 here. Worth deciding how to handle it rather than leaving it to surface repo by repo: 1. have the shared library exclude the generated file when it invokes the build, 2. have `maven-wrapper-plugin` emit a licence header in `maven-wrapper.properties`, which fixes it everywhere at once, or 3. leave it, and let affected maintenance branches add a RAT exclusion when someone touches them. ### What the rerun did confirm 85 green, including every repository in this upgrade, on both `asfMavenTlpPlgnBuild` and `asfMavenTlpStdBuild`, on Maven 3 and Maven 4 branches alike. Builds provision 4.0.0-rc-6 through the wrapper while the nodes still resolve `maven_4_latest` to 4.0.0-rc-5. -- 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]
