[
https://issues.apache.org/jira/browse/MNG-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6976.
-------------------------------
Resolution: Won't Fix
Closing for the following reasons:
* First proposal requires to track a lot of information and analyze them
asynchronously in Maven Resolver, not Maven. This is a lot of work. Unless
someone creates a PR, no change will come from use, trust me.
* I have provided a solution for filtering out download information.
> --no-transfer-progress variant to diagnose download issue
> ---------------------------------------------------------
>
> Key: MNG-6976
> URL: https://issues.apache.org/jira/browse/MNG-6976
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Logging
> Affects Versions: 3.6.3
> Reporter: Jesse Glick
> Priority: Major
>
> {{-ntp}} is very welcome as a way to cut down on log spam. This is especially
> significant in a CI environment where Maven is being run in a virgin
> container/VM with no initial local repository, typically with a settings file
> directing downloads to some local mirror: every {{mvn}} command's output
> would otherwise be 99% transfer messages, making it very difficult to find
> real messages in the middle.
> The problem comes if there is a serious delay or even hang in some transfer.
> Without {{-ntp}}, you could guess that a build was stuck waiting for an
> overloaded Nexus server or the like just by scanning a timestamped log file
> and noticing that some big artifact had been requested but never served, or
> that thousands of little artifacts are being served but take a second each,
> etc. With {{-ntp}}, it is less obvious what is going wrong: there is no
> information about which artifact download is stuck, what the URL of the
> server it is stuck on is, or even whether Maven is waiting for a download at
> all (perhaps it is doing something unrelated).
> Suggestions:
> * Amend {{-ntp}} (or introduce an argument or a variant) so that if a
> particular artifact download is in progress for, say, 10s that a warning is
> emitted with the download URL. Or, if a whole block of downloads during some
> artifact resolution phase is taking more than, say, 5m, print a warning
> summarizing the server(s) in use, the number of artifacts requested vs.
> retrieved, etc.
> * Offer a convenient way to capture the sort of logging produced by {{-B}}
> without {{-ntp}} (i.e., one line per artifact requested or retrieved) but
> direct this to a file rather than the stdout/stderr of the {{mvn}} process,
> so it does not overwhelm a CI log yet can be inspected on demand.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
