LeonxLJX commented on PR #19784: URL: https://github.com/apache/hudi/pull/19784#issuecomment-5538294216
Heads-up on the CI state here, because my earlier comment was chasing the wrong problem. **The workflows on this PR had never actually run** — not failing, never queued. I had been pushing my commits through the GitHub REST API (Contents API `PUT`, then a Git Data API ref update), and neither of those emits a `push` event, so no workflow was ever triggered. The "please re-run all jobs" I asked for was meaningless; there was nothing to re-run. I've now pushed for real over git (`358e436`), which queued all five workflows (Java CI, PR Compliance, PR Title Validation, Commit Co-author Validation, Hudi Trino Connector CI). They are all sitting at **`action_required`** — GitHub's standard gate for a first-time contributor's fork PR — so a maintainer needs to hit **"Approve and run"** once. After that, subsequent pushes from this fork won't need approval again. What's in the branch for whoever reviews it: - **Java 8 compatibility** (the original CI failure): `TestReflectionUtils` no longer calls `InputStream.transferTo(OutputStream)`, which is Java 9+ and doesn't exist on the Java 8 toolchain used by the Scala 2.12 build. Replaced with an explicit 8192-byte buffer copy loop. - **JAR-backed package scanning** (@danny0405, your [P2]): every non-test caller of `getTopLevelClassesInClasspath` is a `packaging/*-bundle/Main`, so dropping `jar:` resources would have broken them. `findClasses(URL, String)` now branches on `"jar".equals(resource.getProtocol())`, opens a `JarURLConnection`, and scans the JAR entries directly, since `new File(uri)` does not accept `jar:` URIs. The `file:` path is unchanged. - **Null handling**: `toDirectory(resource)` can still return `null` for a malformed URI, so the directory branch keeps the null filter the old pipeline had. - **JAR handle caching**: `JarURLConnection.getJarFile()` defaults to `useCaches=true`, and closing that instance in try-with-resources can leave a later `getJarFile()` for the same JAR handing back a closed handle. The connection is now opened with `useCaches=false` before taking the `JarFile`. - Also removed a stray `.ci-retrigger` placeholder file I had added while trying (unsuccessfully) to fire CI from the API. Happy to adjust the approach if you'd rather handle the JAR caching differently — that one is the least obvious of the four. -- 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]
