[MNG-7529] Maven resolver makes bad repository choices
Structure the version checks slightly different to make the separation
between repository versions and the version range resolution clearer.
Ensure that any versions resolved as part of a version range request
only reference repositories that are actually enabled for the type of
version (SNAPSHOT versions against snapshot repos, release versions
against release repositories).
But keep Wagon as default transport. This PR merely includes
resolver http and file transport and switches wagon-http
to non-shaded one.
Changes:
* switch to non-shaded wagon-http (as httpClient is now shared)
* include resolver http and file transport
* override resolver default behaviour (native transport preferred over wagon, when both on classpath)
* provide simplistic means to choose transport
The chosen transport can be seen in debug (-X) output on line
`[DEBUG] Using transporter XXX...`
The `-Dmaven.transport` simplistic switch can be used to choose transport:
* not set: default, that is Wagon
* `wagon`: explicitly sets Wagon
* `resolver`: explicitly sets resolver native transports (file and http)
* `auto`: relies on resolver "auto discovery" (priorities, etc). This is MUST to keep transport pluggable with 3rd party transports. In fact, this was the default so far in Maven, along with the fact that native resolver transports were not included (as resolver prefers native ones over Wagon).
This PR makes VersionScheme a component, is injected where needed
(instead of ad-hoc instantiation), but provides room for
different schemas, as GenericVersionScheme is "default"
but now nothing stops to add other schemes as well.
Maven Artifact Transfer silently prevents group level metadata to reach Resolver and causes metadata loss on install/deploy. Fix is to "bridge" this from maven-resolver-provider (and core) by reusing the actual metadata that m-plugin-p:addPluginArtifactMetadata mojo adds, but m-a-t filters out.
Reuse MavenExecutionRequest#getStartTime() throughout for snapshot versions,
last updated fields in metadata consistently for local and remote repositories
for the entire reactor and its modules.
This closes#381
If a dependency on another project is found, don't parse its
POM again, but instead use the model we already have in memory.
This saves a large amount of time and memory for builds that have
lots of subprojects and dependencies between them.
The approach was directly copied from DefaultArtifactDescriptorReader,
which does the same optimization.
This closes#244
Updated to correctly map the optional flag of Maven model dependencies to
Aether dependencies. Prior to this change all managed dependencies implicitly
had the optional flag set to 'false' leading to Aether managing that flag to
'false' on all managed dependencies when transitive.
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.
Guillaume Nodet
Sylwester Lachiewicz
Henning Schmiedehausen
Tamas Cservenak
Michael Osipov
Arturo Bernal
Guoxiong Li
George Gastaldi
rfscholte
boris-unckel
Nicolas Juneau
Eddie Wiegers
Artem Krosheninnikov
Christian Wansart
Enrico Olivelli
Stefan Oehme
Karl Heinz Marbaise
HoaPhan
Sylwester Lachiewicz
Stephen Connolly
Hervé Boutemy
Igor Fedorenko
Christian Schulte
Josh Soref