File#toURI()#toString() produces a non-compliant URI making tools like
Subversion or Git to choke on those URIs. Whereas Path#toUri()#toASCIIString()
does the right job.
o display deprecation build warning for dependencies with scope 'system' declaration
o Note about tests: existing 'systemPath' related tests are reused/expanded
(rationale: scope 'system' and 'systemPath' are mutually dependent)
Signed-off-by: Karl Heinz Marbaise <khmarbaise@apache.org>
This reverts commit 13adc1bc2b *not changing
anything* just because someone did not react in time when this issue had been
lying around on a branch. If we would set pace for the industrie, everyone would
still be using 5.25" floppy disks and 8 bit hardware and we would tell them
that upgrading to be able to use new software would be too risky and they
better keep theire broken assembly routines until the machine goes up in
smoke.
[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.
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.
Refactoring the current code setting system properties to synchronize correctly on the given ones: avoids ConcurrentModificationException and NullPointerException if the properties is modified by another thread.
- With this change we basically unwind MNG-5840 for the rumoured validation in the workspace resolver
when dealing with a parent version range. Not ideal but only way for now to retain the version range feature
Christian Schulte
Michael Osipov
Sylwester Lachiewicz
Hervé Boutemy
Karl Heinz Marbaise
rfscholte
dejan2609
Alex Henrie
Josh Soref
Guillaume Boué
Stephen Connolly
Jason van Zyl
Robert Scholte