[jira] [Comment Edited] (MNG-7001) Reconsider seemingly useless check of artifacts' source repository introduced in Maven 3.0

["Tamas Cservenak (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MNG-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694468#comment-17694468 ] 

Tamas Cservenak edited comment on MNG-7001 at 2/28/23 10:04 AM:
----------------------------------------------------------------

Regarding the 4 issue in original Jira description:
 # not gonna happen (to remove the availability check)
 # not gonna happen (to make it disabled by default)
 # about to happen, see MRESOLVER-333
 # we all will try out best here

Regarding the two emphasized points from a comment:

Regarding "It should be possible to build your project when going offline, it's quite a valid use case IMO" – best way to "go offline" is to build full project while online (never use -DskipTests, rather make surefire ignore no tests and use -Dtest=void instead). Basically "prime" your local repository before going offline. Many user forget that Maven is not "just the CLI", the CLI is the "visible part" of it only. A good and funny introductory video about the part in shadow  can be seen here: [https://www.youtube.com/watch?v=-9aHJyvNx9k] From discussion above it is clear that in case of "no tool should force you to do so and hinder you from working with your locally downloaded stuff", that "your stuff" is not "maven's stuff", and Maven will want to ensure about it to fulfill it's promise (or project A stuff is not project B stuff to be more precise). Again, prime your local repository. But there are much better ways to achieve this.

Regarding "You can surely imagine working on any kind of project when a repository you depend on simply becomes unavailable" a big mistake: Maven is NOT about availability and never was. If you want availability, you have to use some Maven Repository Manager. Maven considers local repository as transient (hence with and without local repo Maven will happily build happily a healthy project, sure, without local repo it will be a bit longer, as it needs to get stuff for you). Local repository is a cache, it has nothing to do with "availability". And for sure should never be considered as some sort of "availability guarantee" at all. That is a pure mistake.

 


was (Author: cstamas):
Regarding the 4 issue in original Jira description:
 # not gonna happen (to remove the availability check)
 # not gonna happen (to make it disabled by default)
 # about to happen, see MRESOLVER-333
 # we all will try out best here

Regarding the two emphasized points from a comment:

Regarding "It should be possible to build your project when going offline, it's quite a valid use case IMO" – best way to "go offline" is to build full project while online (never use -DskipTests, rather make surefire ignore no tests and use -Dtest=void instead). Basically "prime" your local repository before going offline. Many user forget that Maven is not "just the CLI", the CLI is the "visible part" of it only. A good and funny introductory video about the part in shadow  can be seen here: [https://www.youtube.com/watch?v=-9aHJyvNx9k] From discussion above it is clear that in case of "no tool should force you to do so and hinder you from working with your locally downloaded stuff", that "your stuff" is not "maven's stuff", and Maven will want to ensure about it (or project A stuff is not project B stuff to be more precise). Again, prime your local repository. But there are much better ways to achieve this.

Regarding "You can surely imagine working on any kind of project when a repository you depend on simply becomes unavailable" a big mistake: Maven is NOT about availability and never was. If you want availability, you have to use some Maven Repository Manager. Maven considers local repository as transient (hence with and without local repo Maven will happily build happily a healthy project, sure, without local repo it will be a bit longer, as it needs to get stuff for you). Local repository is a cache, it has nothing to do with "availability". And for sure should never be considered as some sort of "availability guarantee" at all. That is a pure mistake.

 

> 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.20.10#820010)