[
https://issues.apache.org/jira/browse/MNG-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220024#comment-17220024
]
Petr Bodnar edited comment on MNG-7001 at 10/24/20, 9:44 AM:
-------------------------------------------------------------
Thank you guys for taking this further.
So regarding the repo-check, for a start that shouldn't take too much time, I
would suggest:
# To change the error repo-check failure message - this is already covered by
MNG-5185 and should be implemented there, together with completing the
[http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException]
page. From what was written by [~michael-o], it seems to be trivial to do? The
hardest part will be possibly to come up with a good error message (that
authors of the repo-check should have supplied years ago already).
# To skip the repo-check at least when in offline mode (for "-o" and possibly
also for "-nsu"). As this will not change settings model etc., this could be
pretty easy to do. As you guys said, anything else would be too time consuming
to be realized in a reasonable time now.
What do you think?
{quote}If that's not enough we need to figure out why there would be a need to
control the check and solve that.
{quote}
Yes, even though the above gets implemented, I expect complaints from Maven
users will still come. Because together with the "-llr" option, it is just a
_partial_ solution to the problems described. Hopefully some other guys will
come and they will be able to re-explain it to you. I'm already a bit tired
from discussing this when the only argument is that "it solves our problem and
if want to do it differently, you are doing it wrong"...
was (Author: pbodnar):
Thank you guys for taking this further.
So regarding the repo-check, for a start that shouldn't take too much time, I
would suggest:
# To change the error repo-check failure message - this is already covered by
MNG-5185 and should be implemented there, together with completing the
[http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException]
page. From what was written by [~michael-o], it seems to be trivial to do? The
hardest part will be possibly to come up with a good error message (that
authors of the repo-check should have supplied years ago already).
# To skip the repo-check at least when in offline mode (for "-o" and possibly
also for "-nsu"). As this will not change settings model etc., this could be
pretty easy to do. As you guys said, anything else would be too time consuming
to be realized in a reasonable time now.
What do you think?
{quote}If that's not enough we need to figure out why there would be a need to
control the check and solve that.
{quote}
Yes, even though the above gets implemented, I expect complaints from Maven
users will still come. Because together with the "-llr" option, it is just a
_partial_ solution to the problems described. Hopefully some other guys will
come and they will be able to re-explain it to you. I'm already a bit tired
from discussing this when the only argument is that "it solves our problem, so
we will force everybody to use it"...
> 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)
