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.
---
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#1029
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
@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.
This closes#985
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#981
* Split the header on two lines
* Properly delegates equals/hashCode to the v4 models
* Introduce object tracking in settings / toolchains
* Get back to a single template for v3 models
* Switch settings / toolchains mergers to deep merge
* Fix binary compatibility with 3.x
Maven Consumer POM redone, it happens only in "maven3 realm" (before resolver), and allows use cases like m-gog-p and checksum-m-p work as before.
Key aspects:
* consumer POM is injected to build earliest possible as attached artifact
* it lives and is visible just like any other attached artifact (so m-gpg-p can process it)
* just before the install/deploy, they are "swapped out" to replace POM along with all "extras" it may have (checksum, signature)
* to support use cases like MNG-7067 (in memory model is changed, but not POM file), OnChangeTransformer could be extended to take into account both: file content and model content.
---
https://issues.apache.org/jira/browse/MNG-7622
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
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
* Clean a bit DefaultProfileActivationContext
* Cleanup DefaultProjectBuildingResult
* Cache the injected list to avoid repetitive lookups
* Lazily compute the MavenBuildTimestamp
* Use a single loop to select active profiles
Something simple to use and would reuse all the auth/proxy etc data from Maven. Intentionally super-trivial API.
If something more "serious" needed, plugin should probably roll it's own solution.
---
https://issues.apache.org/jira/browse/MNG-7607
* Fix plexus gav
* Install maven instead of just building it
The plugins need to be available in the local repo, else the build may download old snapshots
* Fix DefaultArtifactManager to allow using both Artifact and Dependency
* Add a TODO for an EventSpy related api
* Add simple string/model conversion on the XmlFactory
* Decouple services creation
* Move services to @Singleton scope
* Add protected constructors as builders should not be created directly
* Fix typos "can not" -> "cannot"
* Add some null checks on build(xx) shortcut methods
* Add a some missing conversion to immutable collections for requests
* [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>
# Conflicts:
# maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java
# maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java
To lessen mistake (copy-paste vs forgotten update) but also just to
make things less redundant. This also makes possible "experimenting"
much more easier.
This is merely a refactoring that does not takes or gives anything, just tidies up.
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.
Guillaume Nodet
Slawomir Jaranowski
Hervé Boutemy
Tamas Cservenak
Andrey Bruykhov
Christoph Läubrich
Alexey Venderov
Pavel Horal
Michael Osipov
Konrad Windszus
Olivier Lamy
Simon
Abdel Hajou
Martin Kanters
Sylwester Lachiewicz
Giovanni van der Schelde
Marc Wrobel
Josef Cacek