cstamas commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1345989051
In short: japicmp fails with a reason, this is a breakage. Longer story: We have a page https://maven.apache.org/resolver/api-compatibility.html that explains how we "expect" clients to behave, and what we promise. In this case, this PR breaks our promise. This is why common (but not applied to all) approach is visible on this example: Listener interface https://github.com/apache/maven-resolver/blob/ce54f7f371eaf37657413d7b7135171aa88cba40/maven-resolver-api/src/main/java/org/eclipse/aether/transfer/TransferListener.java FORBIDS direct implementation, instead, it directs you to https://github.com/apache/maven-resolver/blob/ce54f7f371eaf37657413d7b7135171aa88cba40/maven-resolver-api/src/main/java/org/eclipse/aether/transfer/AbstractTransferListener.java support class. Now, we cannot "enforce" this in any way (so "bad" clients still can directly implement interface), but according to that page, then they are "on their own". The presence of support class in chain `iface -> support class -> impl` allows us to introduce methods that would be otherwise breaking. Problem is, WorkspaceReader is NOT introduced in that set (see japicmp config). We may change that of course.... -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
