MNG-7758 workaround

[michael-o]

This has been intentionally broken up into two commits/issues:

• MNG-7771 uses rather synthetic exception messages rather than to rely on the order of exception messages in ArtifactResult. No more first wins.
• MNG-7770 is an attempt to create a workaround meanwhile.

Two IT failures:

• MNG-7128 (repo blocker): The exception for POM contains two exceptions (1) TransferException (blocked), (2) ArtifactNotFoundException (not in file:target/null) , the behavioral change is that the POM is now considered missing and the JAR fails. Previously, it failed already with the POM.
• MNG-3470 (checksum validation fails): Similar case, the checksum validation of the POM fails, it is not considered as missing, the build succeeds since the checksum for the JAR was fine. This is a behavioral change since the validation exception is traded for a not found exception in file:target/null).

See output: https://gist.github.com/michael-o/c9932567ac004a30021d44a464a37dbf

One of the general questions is: When is an artifact consindered not to be found? When ALL repos say not found, or is one sufficient? What if one repo is technically offline which could or could not contain it, then rest does not contain? Why fail the build?

Important reads:

• https://issues.apache.org/jira/browse/MNG-7758
• https://issues.apache.org/jira/browse/MRESOLVER-335

Let me know what you think.

[michael-o]

Here is a non-sense exception message since it uses only the the first result and the first exception:

[ERROR] Failed to execute goal on project service-controller: Could not resolve dependencies for project com.siemens.lda.cafe:service-controller:jar:2.5-SNAPSHOT: The following artifacts could not be resolved: org.awaitility1:awaitility1:jar:3.1.6 (absent), com.siemens.lda.cafe:lda-cafe-module-dd-schema1:jar:1.0.0 (absent): Could not transfer artifact org.awaitility1:awaitility1:jar:3.1.6 from/to lda-public (https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/): status code: 403, reason phrase: Forbidden (403) -> [Help 1]

awaitility1 cannot be searched in lda-public, but for da-cafe-module-dd-schema1 nothing is said because in all repos it gives 404. The message is simply misleading.

Message w/o the patch:

[ERROR] Failed to execute goal on project service-controller: Could not resolve dependencies for project com.siemens.lda.cafe:service-controller:jar:2.5-SNAPSHOT: Failed to collect dependencies at org.awaitility1:awaitility1:jar:3.1.6: Failed to read artifact descriptor for org.awaitility1:awaitility1:jar:3.1.6: Could not transfer artifact org.awaitility1:awaitility1:pom:3.1.6 from/to lda-public (https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/): authorization failed for https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/org/awaitility1/awaitility1/3.1.6/awaitility1-3.1.6.pom, status: 403 Forbidden -> [Help 1]

No word about the second missing dependency.

[cstamas]

Why are ITs failing?

[michael-o]

Why are ITs failing?

Explanation provided above.

[cstamas]

Am really unsure about all this: IMHO it is completely enough for resolver to state "unable to resolve GAV" (something that is absent or present in local repo, and that message is already present), instead to go great lengths and try to figure out instead of user. As you listed, there are MANY tricky situations, like lack oof (or wrong) auth credentials, but again, that does NOT guarantee that if fixed, artifact will be resolved.

IMHO, we should just increase the level of logged causes (maybe even for all tried repositories) and let user figure out?

[michael-o]

Am really unsure about all this: IMHO it is completely enough for resolver to state "unable to resolve GAV" (something that is absent or present in local repo, and that message is already present), instead to go great lengths and try to figure out instead of user. As you listed, there are MANY tricky situations, like lack oof (or wrong) auth credentials, but again, that does NOT guarantee that if fixed, artifact will be resolved.

IMHO, we should just increase the level of logged causes (maybe even for all tried repositories) and let user figure out?

This is why I have asked. How should be an absent dependency defined? Only not found or anything else too? That is why this is a draft.