Petr Bodnar created MNG-7001:
--------------------------------
Summary: 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.6.3, 3.5.4, 3.3.9, 3.2.5, 3.1.1, 3.0
Reporter: Petr Bodnar
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.
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)
