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>
- ca43030313 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.
read ${maven.projectBasedir}/.mvn/extensions.xml and create core
extensions realms during maven runtime bootstrap. this required
short-lived bootstrap plexus container to resolve extensions.
individual extensions realms are wired to maven.ext realm according
to META-INF/maven/extension.xml exported packages specification
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
this is mostly to help integration tests reuse the same realm ids,
but plugging resource leaks is generally a good thing.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
Push MavenExecutionRequestPopulator down to only operate in the MavenCli. Two of the three methods were already called from MavenCli so now all of them are. In the process I deleted a bunch of code and pursue my quest to remove Settings from the core in order to make a general configuration mechanism that can be plugged into the core via the MavenCli.
Also removed the requirement of the LegacyRepositorySystem in the DefaultMavenExecutionRequestPopulator which breaks another tie with the legacy code. I took the bits that were needed and a lot of the code, after tracing through it, is redundant so it has been deleted.
Turning off:
injectMirror( request, request.getRemoteRepositories(), request.getMirrors() );
injectMirror( request, request.getPluginArtifactRepositories(), request.getMirrors() );
in DefaultMavenExecutionRequestPopulator
Results :
Failed tests:
MavenITmng4190MirrorRepoMergingTest>AbstractMavenIntegrationTestCase.runTest:220->testit:76 null expected:<[1]> but was:<[4]>
Tests in error:
MavenITmng4991NonProxyHostsTest>AbstractMavenIntegrationTestCase.runTest:220->testit:89 » Verification
MavenITmng4963ParentResolutionFromMirrorTest>AbstractMavenIntegrationTestCase.runTest:220->testit:58 » Verification
There is mirror evaluation code in DefaultMaven:newRepositorySession( MavenExecutionRequest request ) which appears to
duplicate this logic but not quite enough for the ITs to pass.
---
Turning off:
injectProxy( request.getRemoteRepositories(), request.getProxies() );
injectProxy( request.getPluginArtifactRepositories(), request.getProxies() );
in
DefaultMavenExecutionRequestPopulator
Result:
The ITs pass
So the code is not needed so it has been deleted.
---
Turning off:
injectProxy( request.getRemoteRepositories(), request.getProxies() );
injectProxy( request.getPluginArtifactRepositories(), request.getProxies() );
injectAuthentication( request.getRemoteRepositories(), request.getServers() );
injectAuthentication( request.getPluginArtifactRepositories(), request.getServers() );
in
DefaultMavenExecutionRequestPopulator
Result:
The ITs pass
The code in DefaultMaven:newRepositorySession( MavenExecutionRequest request ) appears to populate proxies and authentication correctly. The injectAuthentication code has been deleted.
---
This is also perfunctory in DefaultMavenExecutionRequestPopulator after tracing through it:
request.setRemoteRepositories( getEffectiveRepositories( request, request.getRemoteRepositories() ) );
request.setPluginArtifactRepositories( getEffectiveRepositories( request, request.getPluginArtifactRepositories() ) );
MavenExecutionRequest has been extended with toolchains, which is filled by MavenCli
Interfaces have been extended with new methods, assuming only Maven provides implementations
Romain Manni-Bucau
Stephen Connolly
rfscholte
Michael Osipov
Dan Tran
Hervé Boutemy
Igor Fedorenko
Stefan Eicher
Karl Heinz Marbaise
August Shi
Alex Henrie
Arnaud Heritier
Josh Soref
Harald Wellmann
Jason van Zyl
Keith Turner
tssp
sugartxy
Kristian Rosenvold
Robert Stern
Robert Scholte