[
https://issues.apache.org/jira/browse/MNG-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216348#comment-17216348
]
Petr Bodnar commented on MNG-7001:
----------------------------------
Thanks for taking your time and for your responses, it looks like we are
finally getting somewhere! :) There seem to be 2 extremely opposite points of
view on this topic - let's try to find some compromise now, OK? I will try to
give at least a partial feedback to your responses:
[~michael-o], yes, I think you described one of the use cases correctly. Just
some additions for making it really clear:
*1. It should be possible to build your project when going offline, it's quite
a valid use case IMO.* Of course that sooner or later you will have to
"reconnect", but no tool should force you to do so and hinder you from working
with your locally downloaded stuff. The only workaround now AFAIK is to delete
the metadata files, which effectively makes the whole repo-check mechanism
nonfunctional on a given machine (what a paradox here, right?).
*2. It's not just about taking your PC from work to home.* You can surely
imagine working on any kind of project when a repository you depend on simply
becomes unavailable.
{quote}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.{quote}
[~rfscholte], to the 1st point, I can see that under some circumstances this is
really desirable, thanks for pointing that out. *Yet, I can't agree with you
that this should be forced and the only behavior.* Why can't we have the
repo-check activated just on our CI server, for example? Also, is it really
always better to fail builds to all developers, or just to the ones that don't
have a given artifact yet? I think you should let us decide. Regarding the 2nd
point, I guess there is no feedback necessary, so I'll skip that.
{quote}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.
{quote}
Again, I can't disagree with you more. There is no dirty hacks or anyone
talking about wanting to ignore anything. *Isn't it still clear that we want a
tool that will be _understandable_ and that will give us _choices_ where it
makes sense*, so that people won't run away to Gradle for example? Please look
at the page
[http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException]
that is referenced from the current error messages when repo-check fails. A
failed repo-check is not listed as one of the reasons there, neither is the
cause clear from the error message alone. (I'm a little bit repeating myself
here, but it looks like it is necessary. :()
{quote}I didn't recall any example related to the offline mode. So often a pom
says more than pages of discussions.
{quote}
Please consider the "offline mode" forced by the '-o' Maven option just a
special case, I don't think it makes a big difference. Of course, I think it
remains questionable why when you tell Maven to work offline, why it still
contacts remote repositories just in order to do the repo-checks...
> 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)
