[jira] [Commented] (MNG-6976) --no-transfer-progress variant to diagnose download issue
[
https://issues.apache.org/jira/browse/MNG-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220262#comment-17220262
]
Michael Osipov commented on MNG-6976:
-
If you think you can comeup with something, I will happily reopen. Consider
that we general don't want to maintain any logging-implementation specific
configuration in Maven. We have SFL4J only at compile time. The rest should
remain at runtime.
> --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)
[jira] [Commented] (MNG-6976) --no-transfer-progress variant to diagnose download issue
[
https://issues.apache.org/jira/browse/MNG-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219317#comment-17219317
]
Jesse Glick commented on MNG-6976:
--
A custom Logback configuration does not seem like a reasonable solution. Need
something short and documented; if not {{-ntp}} itself, then something equally
straightforward. Any usage of Maven from CI really needs this.
Will think about offering a PR to Maven Resolver. Minimally, if some downloads
are in flight yet there has been no output for a while, print the last message
that _would_ have been printed had {{-ntp}} not been in use.
> --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)
[jira] [Commented] (MNG-6976) --no-transfer-progress variant to diagnose download issue
[
https://issues.apache.org/jira/browse/MNG-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173621#comment-17173621
]
Michael Osipov commented on MNG-6976:
-
The second one may be achieved with proper Logback configuration. Please
evaluate yourself with filters.
> --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)
