[MRESOLVER-600] - RFC9457 Implementation

[doddi]

Added an RFC9457Reporter for each of the 3 Transporters.

At the moment I tried to keep the original exception messages if the error response is not an RFC9457 type. This did create a little more complexity in the implementation than is perhaps necessary.
If the exceptions to be thrown can be consisted throughout the transporters then this PR could also be simplified considerably. At the moment I have taken the stance not to make any potential breaking changes in messaging.

Fixes: https://issues.apache.org/jira/browse/MRESOLVER-600

[michael-o]

First of all, it is RFC 9457. With a space and uppercase. I see no processing of the response body at all, JSON is just serialzation. An appropriate exception should extract the fields and populate.

[hboutemy]

@doddi is this addition to maven-resolver automatically used by Maven when dependency is upgraded, to fix https://issues.apache.org/jira/browse/MNG-6795 or does Maven require an update to benefit?

[doddi]

@doddi is this addition to maven-resolver automatically used by Maven when dependency is upgraded, to fix https://issues.apache.org/jira/browse/MNG-6795 or does Maven require an update to benefit?

Maven does not need an update to use it but It will require servers to implement the RFC at their end. This PR will throw the RFC9457 exception when an application/problem+json is received as that is what indicates it is RFC 9457 payload. However, for those that implement RFC 9457 it is a suitable replacement and will overcome the issue with reasonPhrase and Http2

[hboutemy]

ok, IIUC, the exception gets translated into a Maven CLI message without changing Maven core code: nice
I don't know if we have an IT to check that... Looking at https://maven.apache.org/core-its/core-it-suite/surefire-report.html, I don't find anything that looks relevant.
We probably don't have any, or https://issues.apache.org/jira/browse/MNG-6584 would not have happened: this is the type of IT where we need to create a mock repository server, not so easy to write

[doddi]

ok, IIUC, the exception gets translated into a Maven CLI message without changing Maven core code: nice I don't know if we have an IT to check that...

I added https://github.com/apache/maven-resolver/pull/576/files#diff-2a1236811d71180ff302ffca463a0449c3c6c13d0df3ec362c78765b58025d47R503 but not aware of any cli ITs. I will look to do a build of maven with this PR and ensure there is a suitable response observed

[cstamas]

This class looks awkward to me in SPI (not a -1 but...)

[doddi]

Yes I kind of agree but I was trying to ensure that the original exceptions (which are different for each transporter) are not lost and thought the wrapped solution is more convenient (albeit a little ugly) as it is a single call rather than the if/else that would have to replace it.

[doddi]

I would add that to get maven-resolver to build with maven will require an update to https://github.com/apache/maven/blob/64e944792613e241b3faddcb4c793e147f6faa5e/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemSupplier.java#L672 as it will now require passing in an instance of ApacheRFC9457Reporter

[doddi]

I would add that to get maven-resolver to build with maven will require an update to https://github.com/apache/maven/blob/64e944792613e241b3faddcb4c793e147f6faa5e/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemSupplier.java#L672 as it will now require passing in an instance of ApacheRFC9457Reporter

Opted to move to static initialised as suggested. This has the benefit of now no longer changing the transporter constructors so the maven project no longer needs to be changed to make use of these changes. dad87aa

[michael-o]

OK for me, but needs another pair of eyes at least.