Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
3.6.3
-
None
-
None
Description
-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.