Reword the validation warning and add new check for real plugin dependencies in wrong scopes (do not rely on build-time derived descriptor, but on real data instead).
---
https://issues.apache.org/jira/browse/MNG-7786
* [MNG-7743] Make the build work on JDK 20
* the behaviour before the fix was already pretty confusing. JDK 19 and
older do not check the presense of '{' in the constructor, so the
URL object got created, but when converting to file the result would
be e.g. '/../../src/test/remote-repo' which is completely wrong.
But it seems the affected tests did not really care, as all of them
were passing
* Remove forgotten println
Co-authored-by: Yeikel <email@yeikel.com>
* Test with latest JDK
* Do not run ITs with jdk 20, but just the "build itself"
---------
Co-authored-by: Yeikel <email@yeikel.com>
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
# Conflicts:
# .github/workflows/maven_build_itself.yml
# maven-core/src/test/java/org/apache/maven/repository/TestRepositoryConnector.java
And do align them. Max Level is Java 8, but
we had several conflicts, like HttpClient
(used by Wagon but also by Resolver-Transport-Http).
---
https://issues.apache.org/jira/browse/MNG-7670
As setter was added in Maven3. Still, this causes unexpected NPE
during plugin execution, while Maven3 should support Maven2
plugins.
---
https://issues.apache.org/jira/browse/MNG-7759
This is ONLY the reproduction of the problem I found.
If you disable the activeProfile (in buildPom and remove the assert) then all checks pass.
If you enable this profile (provided code) then in several places the ${project.basedir} has been interpolated and shows the path of the build and the assertions fail the build.
---
https://issues.apache.org/jira/browse/MNG-7750
This is general rework of current Maven 3.9.x line how it handles plugin and mojo validations.
Changes:
* added plugin validations for dependencies
* introduced pluginValidationManager that gathers violations
* manager creates a report at build end, with dense and non repeating data
* this is in spirit to lessen already too verbose logging, as current solution would report violations as many times plugin is used in reactor, and that can be many (ie. a plugin from parent for each module)
Example report of Maven 3.9.x build: https://gist.github.com/cstamas/b62fdcd53eaf316123cf183f5a24e6a5
---
https://issues.apache.org/jira/browse/MNG-7754
The original fix MNG-7672 matched the "scope" but missed the "order". `project.collectedProjects` are in order as loaded (POM order), is not topologically sorted.
Fix is to use DAG of projects, ask for downstream projects (will return more then we need but sorted) and narrow that list to only contain collected projects.
Related commit: 48cac1c003
---
https://issues.apache.org/jira/browse/MNG-7720
If ConcurrencyDependencyGraph#getRootSchedulableBuilds returns an empty
list then MultiThreadedBuilder is locked forever as it never gets a
build result (because nothing is scheduled).
This changes the method, that in such case just the first project is
returned, this might not give the best performance, but ensures that
there is at least one build scheduled and the build-loop can proceed.
This closes#1028
There is really no need for it, and there is a resolver
option if really must (but really should not, local repo
is and should be considered as transient).
---
https://issues.apache.org/jira/browse/MNG-7713
Older clients (like pyliglot) will miss to inject ModelCacheFactory
as their Plexus XML will not contain that requirement. For them,
provide OOTB defaults.
This would not happen, if JSR330 used, as then Sisu would remedy
this at runtime, but Plexus XML actually puts things in "concrete"
during build time.
---
https://issues.apache.org/jira/browse/MNG-7693
@Deprecated annotatio is helpful to prevent usage of deprecated API.
For example: developer can see crossed out method/field name if this item
is deprecated.
Currently, if a project is returned from the workspace reader, but is not part
of the reactor, a NPE occurs. In this case, the repositories are read from
the model instead.
This closes#805
This immediately cuts in "half" the count of HTTP requests against Maven Central or any major MRM.
Altering the meaning of "default": is now same as "auto", but still leaving it in place for future, as "default" at some point may again become something different than "native".
---
https://issues.apache.org/jira/browse/MNG-7608
Adds Maven feature that is able to explain why an artifact is present in local repository.
Usable for diagnosing resolution issues.
In local repository, for each artifact it records `.tracking` folder, containing farthest artifact that got to this artifact, and the list of graph nodes that lead to it.
Note: this is based on by @grgrzybek proposal and reuses some code he provided. See https://github.com/apache/maven-resolver/pull/182
---
https://issues.apache.org/jira/browse/MNG-7619
Now that Maven 3.9.x contains other transports than Wagon, the Plexus XML is not just to be "stuffed", but translation should happen to proper resolver configuration to make them available to all transports.
---
https://issues.apache.org/jira/browse/MNG-7614
LocalRepositoryManager needs configurations from RepositorySystemSession
so must be created after session configuration is finished.
(cherry picked from commit b1c1f7556d)
* [MNG-7474] SessionScoped beans should be singletons for a given session
Now that the Session is not cloned anymore, we can revert to the original
(Maven < 3.3) behavior of the session scoped components.
Co-authored-by: Christoph Läubrich <christoph@laeubi-soft.de>
This closes#743
* Remove setting a value which is the default already
Co-authored-by: Christoph Läubrich <christoph@laeubi-soft.de>
Instead of user properties, as this allows making "permanent" the
selection by using MAVEN_OPTS and other places as well. Currently
only via command line works.
Also, do not modify existing Maven behavior, so introduce "default" branch
in selection. See comment in code
Problem: resolver spi, impl and connector-basic has changes in 1.8.0 (SPI interface RepositoryLayout got new method, that is implemented in connector-basic, and code from impl is using it). But, Maven core exports only resolver api, spi and impl packages, while the rest is at mercy of a plugin. This means ,that these artifacts (api, spi and impl) will always come from Maven core, whatever version plugin declares, while the "rest" (connector-basic and util) will be of version that plugin declares. The current state hence prevented ANY KIND of changes on SPI interfaces that would be implemented in connector-basic (which is the case in Resolver 1.8.0).
Solution: make all these resolver artifacts "provided" (to behave like maven-core or maven-plugin-api is behaving): simply put, whatever resolver artifact plugin depends on, it should NOT use it's own version, but the version from Maven. This ensures that api-spi-impl-connector-basic as "aligned" and are same version.
Details:
The change is to make util is exportedArtifact AND exportedPackage, while connector-basic is only exportedArtifact.
Reasoning:
* exportedArtifact -- prevents "own" artifact to be added to realm
* exportedPackage -- makes it "visible" in realm
So, this basically prevents bad versions of util and connector-basic
enter the plugin realm (as they will be not added to it), while
util remains "visible" to plugins, as the intent was, most
common due GenericVersions etc.
This change also results in simpler expectations to plugin developers:
resolver libraries should really behave like maven-core or maven-compat:
when plugin declares dependency on these (w/ scope provided as best
practice), they really get version of these that are of version that
maven runs in, not version they declare. So same thing happens now with
resolver: you will get same version of resolver that maven uses your plugin
runs in.
Before this change, it was a mixed bag: api, spi and impl was from maven,
while util and connector-basic was version you pulled in as dep.
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.
This is backport of commit d141957ff5 from master to maven-3.9.x branch.
Addendum to 1ad5a1b1e9bb0a17fc12bbe0314564a616078602:
* fix property name to align with existing ones
* fix logging configuration as no more shaded httpClient
* fix constant names
[DEBUG] Configuring mojo execution
'org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test:default-test'
with basic configurator
rephrase "Configuring" to "Loading" mojo "from plugin realm"
to differentiate from "configuring mojo" = apply configuration
rename populatePluginFields(..) private method
to populateMojoExecutionFields(..) to better match the intent
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).
- Added warning when setting deprecated parameter with value different
than the default.
- Changed Logger to SLF4J.
(cherry picked from commit c99028b9fb)
The commit c604db3c3a
changed ReactorReader to use MavenSession#getAllProjects()
instead of deprecated MavenSession#getProjectMap() that
is equivalent of MavenSession#getProjects().
This undoes this unintended change.
As Resolver session contains non-MavenWorkspaceReader, the reactor models (already resolved w/ profiles applied) are re-built when using Resolver within Mojo, instead to get them via ReactorReader as expected. The rebuilt models will lack explicit (-P on CLI) profiles applied, as resolver itself is not maven aware, hence there is no way to "tell" resolver to apply them. Building reactor models w/ profiles applied is NOT done using resolver, but by Maven when loading up reactor, as profiles are NOT applied for downstream transitive dependencies (see discussion on MNG-1388 why).
Signed-off-by: Christoph Läubrich <christoph@laeubi-soft.de>
Co-authored-by: Christoph Läubrich <christoph@laeubi-soft.de>
Co-authored-by: Tamas Cservenak <tamas@cservenak.net>
Tamas Cservenak
Petr Široký
Guillaume Nodet
Grzegorz Grzybek
Niels Basjes
Slawomir Jaranowski
Andrey Bruykhov
Christoph Läubrich
Pavel Horal
Michael Osipov
Simon
Piotrek Żygieło
Abdel Hajou
Sylwester Lachiewicz
Hervé Boutemy
Josef Cacek
Gabriel Belingueres
Karl Heinz Marbaise
Jacky
mickroll
boris-unckel