[
https://issues.apache.org/jira/browse/MNG-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216178#comment-17216178
]
Robert Scholte commented on MNG-7001:
-------------------------------------
I'll start with option 4: the check is required to ensure the same result of
builds _at any time_. History shows we need such check for cases like:
* disappearing or renamed repositories: if your project contains artifacts
from a removed repo, it might build for you, but for a someone who checks it
out the first time, it'll fail. For that reason it should also fail for you, so
you can fix it.
* same groupid+artifactid+version, different content at different repos. Yes,
we've seen this (IIRC command-lang) and it can drive you insane as everybody
expects these are the same everywhere.
The first 3 options all works towards the dirty hack: I've never had that
issue, so let me ignore it, at least don't bother me with the message.
I didn't recall any example related to the offline mode. So often a pom says
more than pages of discussions.
> Reconsider seemingly useless check of artifacts' source repository introduced
> in Maven 3.0
> ------------------------------------------------------------------------------------------
>
> Key: MNG-7001
> URL: https://issues.apache.org/jira/browse/MNG-7001
> Project: Maven
> Issue Type: Improvement
> Affects Versions: 3.0, 3.1.1, 3.2.5, 3.3.9, 3.5.4, 3.6.3
> Reporter: Petr Bodnar
> Priority: Major
>
> This problem of "by-nobody-really-requested check for artifacts' source
> repository" (just "repo-check" further on) is actually considered a bug by
> many Maven users. It was introduced back in Maven 3.0, 10 years ago \(!). The
> repo-check and its _practical_ disadvantages have been already thoroughly
> described for example in my blog
> [here|https://programmedbycoincidence.blogspot.com/2019/01/the-biggest-wtf-new-feature-ive-ever.html]
> and discussed here within Jira: MNG-5181, MNG-5185, MNG-5289 and MNG-5883.
> *TL;DR What is requested in this issue:*
> # Remove the repo-check altogether.
> # If that's not possible, make the repo-check disabled by-default and have an
> option to enable it for those who need it for whatever reason.
> # If even that is not possible, alter Maven and its warnings and errors so
> that they do not confuse users.
> # Reason about the need for the repo-check, document the reasons.
> ----
> The repo-check can be _somewhat_ avoided by passing the {{-llr}} option to
> Maven. AFAIK though, e. g. Eclipse's embedded Maven used for dependency
> resolution doesn't support this option. Another long-outstanding issue is
> that using the {{-llr}} option generates this warning on Maven build:
> {noformat}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {noformat}
> Generally it might make sense (possibly because of activating some quite
> another old part of Maven that, apart from other things, doesn't mark down
> the artifacts' sources to "\*.repositories" files?). But when users have _no
> other option_ that could be used for making their build reproducible by
> skipping the repo-check, then the warning doesn't make sense to them. The
> only other choice they have is to remove all those "\*.repositories" files
> from their local Maven repository in order to make their builds work again.
> Another mind-blowing issue is described in MNG-5185: If an already-downloaded
> artifact doesn't go through the hard-coded repo-check, Maven just tells the
> user "the artifact could not be resolved". _But you'll get the very same
> message when downloading an artifact really fails._ So unless you dig in,
> these two totally different situations are not distinguishable from each
> other.
> ----
> Yet to date, no action was taken by Maven authors to help with any of the
> problems. There is also no really good (read "making-sense-in-real-life")
> explanation of real pros of the introduced repo-check, that would out-weight
> its cons, other than for example:
> {quote}The artifacts have an identity. It matters where the artifacts were
> downloaded from. Artifact A downloaded from X is not the same thing to Maven
> 3 as A downloaded from Y. This can happen when you flip your settings.xml to
> go from using a repository manager to using Maven Central directly for
> example.
> {quote}
> (taken from MNG-5289 comment)
> The logical question here is, to whom concretely "it matters"? Please, give
> examples of what could go wrong if one has downloaded a released version of
> an artifact and now its source repository changes or becomes unavailable.
> Please note that we shouldn't consider the very improbable case of artifacts
> downloaded from various repositories would have different content even though
> having the very same GAV. The Maven's local repository filesystem structure
> is not able to cope with that situation anyway, or is it?
> Finally, there is also a performance-wise con of the repo-check - Maven needs
> to contact the source repository every time it builds a project referencing
> the checked artifact as one of its dependencies. Or doesn't it?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
