gnodet commented on PR #1955: URL: https://github.com/apache/maven-resolver/pull/1955#issuecomment-4958265892
I agree with @cstamas that the SPI module should not pull in a logger dependency, and that a `Consumer`-based approach would be a cleaner design. Here's a possible direction: 1. **Define a callback in the session config** — something like a `BiConsumer<Integer, String>` (status code + body excerpt) that transports call when they encounter a non-RFC 9457 error response with a body. This keeps the SPI clean and lets the integrator decide what to do with it. 2. **Keep it simple for collection** — cstamas's suggestion of "last one wins" (overwriting previous) is the simplest and avoids unbounded memory growth. Alternatively, a small bounded list (e.g., last 3) could give enough context without being overwhelming. The consumer itself can decide the retention policy. 3. **Truncate at the source** — regardless of the collection strategy, the transport should truncate the body before passing it to the consumer (e.g., first 4 KiB). This avoids materializing multi-megabyte HTML error pages in memory. 4. **Display at build end on failure** — Maven (as integrator) could register a consumer that collects these, then displays them in a "diagnostic hints" section when the build fails. This addresses the original issue #1844 intent better than DEBUG logging, since users would see the response body without needing to enable debug. For the session config key, something like `aether.transport.http.errorBodyConsumer` would follow the existing naming conventions. This way the SPI stays dependency-free, the body is available where it matters (build failure output), and the transport implementations just need to call the consumer when they have a response body to report. -- 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]
