There is some unnecessary code in the MavenCli.java from line #1465 to #1474.
The functionality has been moved to line #1215.
Signed-off-by: Karl Heinz Marbaise <khmarbaise@apache.org>
- ca4303031357a7decaee8de770b71fb2c2fedd28 used a hack to reverse the order of arguments
- The side effect of the hack is that the first named system property value on the CLI would win
- The side-effect is causing a lot of integration test builds to fail and will likely have other unintended consequences
- Correct fix is to put system properties at the end.
- If this change passes the integration tests then it will need to be augmented to correctly round-trip the CLI options
as there is the potential that somebody may legitimately be passing an arg parameter a value that starts with -D
for example 'mvn -ep -Dsecretpassword' or 'mvn -l -D.log' but given that this requires a parse and unparse
to handle the escaping, I want to get evidence that the integration tests pass first
.mvn/maven.config
o Reversed the order of properties only to get the properties from
command line at the end of the properties list which results
in correct behaviour to be able to overwrite properties from
command line for properties which have been defined in
.mvn/maven.config file.
* Variable has been removed and replaced with an internal one which
cannot be overriden from outside. From now on, it is an
implementation detail which it should have been from the beginning.
* Cleaned up license header and style of the variable description
section graciously borrowed from the Tomcat start scripts.
Set maven.conf to default ${maven.home}/conf in ${maven.home}/bin/m2.conf
to have a canonical property pointing to global configuration files from
within Java code.
This also helps package maintainers to decouple the Maven installation
from a global configuration by solely modifying m2.conf instead of using
dirty hacks, if possible at all.
* Applied a general decimal formatter which automatically scales file sizes between [0,10) (one decimal digit) and [10,1000) (whole numbers) along with proper size and time units
* The progress meter will now properly
** tell the amount of transfers along with file names (in debug mode) and absolute progress by size
** visually seperate parallel transfers with " | "
* Optimized and reduced padding to the cases where it actually is necessary
* Padding has to be applied to every event which can succeed with progress update
* Synchronize all calls to console to avoid race conditions where output is terminated by a carriage return only. If no sync is done, SLF4J or INIT/SUCCEEDED update can interleave and overwrite the progress while being shorter as the progress itself.
* Replaced the concurrent hash map with a synchronized linked hash map to retain order of the progress meter. It will behave now like a queue.
* Work around a rounding bug existed upto Java 7
See http://stackoverflow.com/q/22797964/696632 and Oracle's bugfix
Announcement: http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
Race conditions cannot be avoided if -T is employed since one does not have access to the output stream of a SLF4J backend to synchronize on.
