[
https://issues.apache.org/jira/browse/MNG-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147771#comment-15147771
]
Michael Osipov edited comment on MNG-5977 at 2/15/16 9:09 PM:
--------------------------------------------------------------
Hervé, here are the two files for console output. The current fix addresses
point 1 and 2. It also reduces information when a file has already been
downloaded/uploaded but still in the pipeline.
I am afraid, I have to fix this issue in two steps due to the complexity. The
first is already locally fixed, the second one is a concurrency issue: The
write operations to the {{PrintStream}} aren't synchronized but should be.
Since there is no guarantee that your line will properly written without been
overridden by another concurrent call. I have observed this during improvement.
Addtionally, the writes to the {{lastLineLength}} aren't synchronized too. One
would probably need to use a {{ReentrantLock}}. Moreover, if a parallel
download happens you basically do not know which progress is which. I want to
print out {{filename: xx kB/yy kB filename: xx kB/yy kB etc.}} since this
might get longer as one download/upload URL itself, proper blank filling has to
be applied. [Here|http://stackoverflow.com/a/9459886/696632] is a good
reference.
At last, if you take closer look at the log files, you see that downloads
disapprear but you never see a "Dowloaded" notification. This is strange too.
Though, this disbalance also exists with {{-B}}/{{--log-file}} mode. There must
be some reason for this.
was (Author: michael-o):
Hervé, here are the two files for console output. The current fix addresses
point 1 and 2. It also reduces information when a file has already been
downloaded/uploaded but still in the pipeline.
I am afraid, I have to fix this issue in two steps due to the complexity. The
first is already locally fixed, the second one is a concurrency issue: The
write operations to the {{PrintStream}} aren't synchronized but should be.
Since there is no guarantee that your line will properly written without been
overridden by another concurrent call. I have observed this during improvement.
Addtionally, the writes to the {{lastLineLength}} aren't synchronized too. One
would probably need to use a {{ReentrantLock}}. Moreover, if a parallel
download happens you basically do not know which progress is which. I want to
print out {{filename: xx kB/yy kB filename: xx kB/yy kB etc.}} since this
might get longer as one download/upload URL itself, proper blank filling has to
be applied.
At last, if you take closer look at the log files, you see that downloads
disapprear but you never see a "Dowloaded" notification. This is strange too.
Though, this disbalance also exists with {{-B}}/{{--log-file}} mode. There must
be some reason for this.
> Improve output readability of our MavenTransferListener implementations
> -----------------------------------------------------------------------
>
> Key: MNG-5977
> URL: https://issues.apache.org/jira/browse/MNG-5977
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Embedding
> Affects Versions: 3.3.9
> Reporter: Michael Osipov
> Assignee: Michael Osipov
> Fix For: 3.4.0
>
> Attachments: current.zip, improved.zip
>
>
> The current output of Downloading/Downladed/Uploading/Uploaded transfer
> notification has some flaws:
> 1. It does not scale numbers between 1 and 1000 with appropriate units
> 2. It uses incorrect size and time units
> 3. When Aether downloads in parallel (which applies for non-POM files) the
> progress interleaves and you do not know to which resource a progress belongs.
> Let's use MPIR {{DependenciesRenderer}}'s
> [{{FileDecimalFormat}}|https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/dependencies/renderer/DependenciesRenderer.java#L1583]
> for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
