[
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:33 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, so
we will force everybody to use it"...
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. 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)
