From issues-return-174304-archive-asf-public=cust-asf.ponee.io@maven.apache.org Sun Oct 18 12:13:03 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mxout1-he-de.apache.org (mxout1-he-de.apache.org [95.216.194.37]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 5B268180648 for ; Sun, 18 Oct 2020 14:13:03 +0200 (CEST) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-he-de.apache.org (ASF Mail Server at mxout1-he-de.apache.org) with SMTP id A7137641E1 for ; Sun, 18 Oct 2020 12:13:02 +0000 (UTC) Received: (qmail 11314 invoked by uid 500); 18 Oct 2020 12:13:01 -0000 Mailing-List: contact issues-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@maven.apache.org Delivered-To: mailing list issues@maven.apache.org Received: (qmail 11296 invoked by uid 99); 18 Oct 2020 12:13:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Oct 2020 12:13:01 +0000 Received: from jira2-he-de.apache.org (static.54.33.119.168.clients.your-server.de [168.119.33.54]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 0C66A41189 for ; Sun, 18 Oct 2020 12:13:00 +0000 (UTC) Received: from jira2-he-de.apache.org (localhost.localdomain [127.0.0.1]) by jira2-he-de.apache.org (ASF Mail Server at jira2-he-de.apache.org) with ESMTP id 3E283C80754 for ; Sun, 18 Oct 2020 12:13:00 +0000 (UTC) Date: Sun, 18 Oct 2020 12:13:00 +0000 (UTC) From: "Robert Scholte (Jira)" To: issues@maven.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (MNG-7001) Reconsider seemingly useless check of artifacts' source repository introduced in Maven 3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MNG-7001?page=3Dcom.atlassian.j= ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D172161= 78#comment-17216178 ]=20 Robert Scholte commented on MNG-7001: ------------------------------------- I'll start with option 4: the check is required to ensure the same result o= f 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. Y= es, we've seen this (IIRC command-lang) and it can drive you insane as ever= ybody expects these are the same everywhere. =C2=A0 The first 3 options all works towards the dirty hack: I've never had that i= ssue, so let me ignore it, at least don't bother me with the message. I didn't recall any example related to the offline mode. So often a pom say= s more than pages of discussions. > Reconsider seemingly useless check of artifacts' source repository introd= uced 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 r= epository" (just "repo-check" further on) is actually considered a bug by m= any Maven users. It was introduced back in Maven 3.0, 10 years ago \(!). Th= e repo-check and its _practical_ disadvantages have been already thoroughly= described for example in my blog [here|https://programmedbycoincidence.blo= gspot.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 hav= e 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 s= o 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 t= o Maven. AFAIK though, e. g. Eclipse's embedded Maven used for dependency r= esolution doesn't support this option. Another long-outstanding issue is th= at using the {{-llr}} option generates this warning on Maven build: > {noformat} > [WARNING] Disabling enhanced local repository: using legacy is strongly d= iscouraged 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 _n= o other option_ that could be used for making their build reproducible by s= kipping the repo-check, then the warning doesn't make sense to them. The on= ly other choice they have is to remove all those "\*.repositories" files fr= om their local Maven repository in order to make their builds work again. > Another mind-blowing issue is described in MNG-5185: If an already-downlo= aded artifact doesn't go through the hard-coded repo-check, Maven just tell= s the user "the artifact could not be resolved". _But you'll get the very s= ame message when downloading an artifact really fails._ So unless you dig i= n, 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-weigh= t its cons, other than for example: > {quote}The artifacts have an identity. It matters where the artifacts wer= e downloaded from. Artifact A downloaded from X is not the same thing to Ma= ven 3 as A downloaded from Y. This can happen when you flip your settings.x= ml to go from using a repository manager to using Maven Central directly fo= r example. > {quote} > (taken from MNG-5289 comment) > The logical question here is, to whom concretely "it matters"? Please, gi= ve examples of what could go wrong if one has downloaded a released version= of an artifact and now its source repository changes or becomes unavailabl= e. > Please note that we shouldn't consider the very improbable case of artifa= cts downloaded from various repositories would have different content even = though having the very same GAV. The Maven's local repository filesystem st= ructure 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 n= eeds to contact the source repository every time it builds a project refere= ncing the checked artifact as one of its dependencies. Or doesn't it? -- This message was sent by Atlassian Jira (v8.3.4#803005)