[MNG-6057] Problem with CI friendly usage of ${..} reactor order is changed
o Based on the missing replacement of the versions ${revision}
${changelist} or ${sha1} within the parent element the order
of the reactor changes.
[MNG-5895] Problem with CI friendly usage of ${..} which is already
defined via property in pom file.
This commit removes the initialization of the MavenSession object from the
DefaultGraphBuilder. The GraphBuilder implementation should only build the
graph and should not touch the MavenSession object passed into it.
To allow complete initialization of the MavenSession the ProjectDependencyGraph
interface got enhanced so that GraphBuilder implementations can communicate all
collected projects in addition to the processed list of projects.
This closes#105
- 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
o Updated to fix parent version range resolution broken since 3.2.3 and to
remove parent version range resolution logic obsolete since Maven
3.2.3 which changed the initialization of MavenProject instances.
o Updated local parent resolution to behave the same way remote parent
resolution behaves. When referencing a parent using version ranges,
inheriting the version or using version expressions should not be supported.
It has been implemented that way for remote parent resolution as it got
introduced in Maven 3.2.2. For local parent resolution the version in parent
declarations had been ignored completely as of Maven 3.3.0 due to commit
be3fb20032 removing all local parent version
validation. Work on fixing this is tracked by MNG-5840 released with Maven
3.3.9. This commit adds the final missing bits to make local and remote parent
resolution behave the same way as much as possible. As an exception, remote
parent resolution still is a bit more strict than local parent resolution due
to a different API in use. When resolving a parent from a repository using
version ranges, the ModelBuilder verifies the range in use to declare an upper
bound. When resolving a parent locally using version ranges, those ranges are
not required to declare an upper bound because the API in use does not support
querying that. Authoring a POM relying on this difference should be considered
a bug.
o Added test cases to maven-core testing parent version range resolution for
local and remote parent models.
commit f3f981022f9157e9d74a9d9dfef7ae102c4d0593
Author: rfscholte <rfscholte@apache.org>
Date: Thu Feb 9 11:00:17 2017 +0100
[MNG-6109] PluginDescriptor doesn't read since value of parameter
There's no specific IT, just a unittest, so itBranch should stay on master
commit 862e8e4e3a2b857eeeb4761a1568c15ebb442932
Author: rfscholte <rfscholte@apache.org>
Date: Wed Feb 8 21:55:30 2017 +0100
[MNG-6109] PluginDescriptor doesn't read since value of parameter
commit 76b539ecf2733b2a8564c18581d60176dc0185a3
Author: rfscholte <rfscholte@apache.org>
Date: Mon Oct 31 21:05:28 2016 +0100
PluginDescriptor doesn't read since value of parameter
JCL over SLF4J has been added also as a runtime dependency because the
bundled HttpClient still uses Commons Logging and we want our version
of SLF4J enforced.
rfscholte
Christian Schulte
Karl Heinz Marbaise
Hervé Boutemy
Christoph Böhme
Stephen Connolly
August Shi
Michael Osipov
robert.patrick
Christian Schulte
Alex Henrie
Archimedes Trajano
Josh Soref
Arnaud Heritier
Stuart McCulloch
Harald Wellmann