* [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>
Previously, to locate plugin configuration in the project the plugin descriptor
was read and the GA were extracted. This always worked because the GA from the
model and the GA from plugin descriptor (plugin.xml) were identical. When a
plugin is relocated the target artifact is read, thus its plugin descriptor as
well. Naturally, the GA of new (relocated) does not correspond to the old
(static) one in the model. Therefore, the configuration is not found.
New approach is to use the original plugin GA to locate the configuration in
the model regardless of relocation.
Revert "[MNG-7251] Fix threadLocalArtifactsHolder leaking into cloned project"
This reverts commit 4e5b3d5554.
Revert "[MNG-6843] Parallel build fails due to missing JAR artifacts in compilePath"
This reverts commit 76d5f0d942.
===
This closes#595
Both plexus-cipher and plexus-sec-dispatcher have had a
groupId change, but plexus-cipher change was implemented
for 1.8 version.
Latest versions of artifacts are 2.0. This PR
ups plexus-cipher version and adds proper changes
for plexus-sec-dispatcher groupId change.
This closes#534
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
The plugin key is build as combination of artifactId and groupId but not
updated if either of these two ids change.
This can be a problem if artifactId or groupId is a variable. The calculated
key will likely contain the unresolved property and is not updated once the
variable is interpolated.
This closes#372
Recent changes in ProjectBuilder make that the compile roots could be
set erroneously on 1st phase and propagated in the results.
This patch just skips setting the compile source root in the 1st pass
(when buildParentIfNonExisting==false).
It also tests some other fields of MavenProject
Reviewers: Michael Osipov, Robert Scholte, Hervé Boutemy
This closes#274
Otherwise the sessionFinished event may be sent before some
projects/goals finish, which violates the contracts of execution
listeners and makes it hard to properly life cycle components that
are needed for goal execution.
This closes#272
This map is not used by Maven and the computation can be quite heavy, so lazily
compute it. In addition, do not clone the map as it's an unmodifiable one already.
This closes#263
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
ExcludesArtifactFilter was highly inefficient.
It took the group and artifact ID of an Exclusion, concatenated them into
a new String, which was kept in memory for the whole duration
of the build and then compared that String against the concatenation
of group and artifact ID of each incoming artifact, adding more
CPU cycles than necessary.
Instead we now just wrap the existing Exclusion object and check its
groupId and artifactId against the artifact to tell whether it should
be excluded.
The old class is kept around for binary compatibility, but is now unused.
Closes#243
* [MNG-6405] Fix basedir in MavenProject.deepCopy.
* Reproduced bug in test.
Failure without patch:
junit.framework.AssertionFailedError: Base directory is preserved across clone expected:<…/maven-core/target/test-classes> but was:<…/maven-core/target/test-classes/target>
at org.apache.maven.project.MavenProjectTest.testCloneWithBaseDir(MavenProjectTest.java:188)
* Code style. Not enforced in tests during build?
Initialize the interim project with "simple" items (ie do not build
not reference parent if it's not yet in the projectIndex) and returns
it when installation fails further.
This give a partial validation of the file, pretty convenient in IDEs.
The global model cache introduced in MNG-6311 causes severe regressions
in case of POM files changing during application lifetime.
This patch adds a system property
`defaultProjectBuilder.disableGlobalModelCache` that disables this global
model cache when set to true, ensure pom modifications are honored.
This closes#194