gnodet commented on code in PR #2205:
URL: https://github.com/apache/maven-resolver/pull/2205#discussion_r4252180765
##########
maven-resolver-spi/pom.xml:
##########
@@ -43,6 +43,10 @@
<groupId>org.apache.maven.resolver</groupId>
<artifactId>maven-resolver-api</artifactId>
</dependency>
+ <dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-api</artifactId>
+ </dependency>
Review Comment:
`PathProcessorSupport` is published in the SPI module precisely because it
is the canonical base class for third-party `PathProcessor` implementations —
`DefaultPathProcessor` in `maven-resolver-impl` already extends it, and so does
`TestPathProcessor` in `maven-resolver-test-util` (a shipped artifact).
Embedding slf4j logging in that base class is therefore appropriate:
implementors extending `PathProcessorSupport` should not have to re-implement
the Windows retry/fallback machinery, and they need a logger to go with it. All
downstream modules already bring `slf4j-api` themselves so the transitive dep
has zero practical impact, but the compile-scope declaration here is the honest
contract: "this base class uses SLF4J."
Moving `PathProcessorSupport` to `maven-resolver-impl` would break every
third-party embedder that extends it from the SPI and would be a breaking
change.
--
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]
