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