We have a build that has configured several Nexus repositories.
Those repositories are located on the very same server, but have various paths (due to user access management).
Sometimes a project publishes to a wrong path and – no idea why – this artifact is corrupt.
However, the correct artifact is also there - but located in another repository (path).
Project builds refer to a init.gradle file where all repositories are configured.
(Gradle <5, no further pattern configuration in init.gradle)
The problem is: whenever a build is resolving a corrupt artifact it stops execution not proceeding with any other repository.
Is this behaviour expected?
What is the reason?
I’d expect Gradle to watch out for a good artifact somewhere else.
(Yes, I know that there are better ways to configure repositories and there should never be a corrupt upload, but it’s a weird legacy build with no one caring…)
Yes, this is expected and documented behavior.
It is not so much about corrupt or not-corrupt.
Gradle goes through the list of repositories in declaration order where the artifact could be present according to configured content-filtering rules.
The first repository that has the requested version of the requested artifact is used and no further artifacts are looked at.
Also if you e.g. have version 1-5 in the first repository and 6-10 in the second repository and request a dynamic version like
+, you will end up with version 5, as the first repository has a suitable version and thus no further repositories are looked at.
Why that decision was made I do not know, but I guess due to performance reasons. Usually a dependency should not be available in multiple repositories, especially not with the same version. so it would be a waste of time in most cases to look further if a match was found.
Yes, that was also my understanding of how it works.
It totally makes sense.
However, it’s annoying in that specific scenario where a project that is using an old Gradle cannot or does not want to upgrade and enhance their build nor process.
Thank you for that fast answer.
(I just hoped for an exception for corrupt artifacts )
That would be quite bad. That would mean a download error due to bit-flip would produce a different build result.