(that are not applicable, but look ugly).
These tests are NOT built, but are taken from real projects
several years ago, and used in POM related UTs.
Hence, for example update of velocity is completely okay,
even if in "real life" it would not compile.
This is most probably "just" about broken Throwable implementations.
Some override getCause but does not perform checks to what it was inited
as "this" means "not yet inited" actually.
---
https://issues.apache.org/jira/browse/MNG-7846
Changes:
* always parse it at session start
* hence, will WARN if needed there as well, and will warn once
* do not re-parse and possibly warn always, reuse parsed enum
---
https://issues.apache.org/jira/browse/MNG-7823
Given maven-shared-utils is being deprecated (see MSHARED-1269), we need to remove its usage in maven. Maven core only uses the logging/message related classes from maven-shared-utils, so this PR enhance the initial v4 api with the needed interfaces and move the jansi specific code into maven-embedder.
* Move maven-compat to jsr330
* Remove more ties to RepositorySystem
* Move more stuff to maven-compat
* Move PluginManager and LocalRepositoryNotAccessibleException to maven-compat
* Fix tests
* Break circular dependency loop in components
* Move unused deprecated classes
Checks the paths before relativizing them.
Normalize and relative before adding to result
Rename local vars
Apply to ExecutionEventLogger
---
https://issues.apache.org/jira/browse/MNG-7795
Co-authored-by: Andreas Dangel <adangel@apache.org>
Refactored and now dropped the unused pluginDescriptor/dependencies validation. Now we have "plugin dependency" (using POM) components to perform dependency validation.
Also, two "inlined" validation from plugin dependencies resolver factored out to components, along with 3 existing moved to newly added (they were wrongly validating descriptor dependencies while intent was to validate "real" dependencies) validators.
Ported from
6c562a46ee
---
https://issues.apache.org/jira/browse/MNG-7789
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>
This commit introduces three properties:
* project.rootDirectory: the project's directory or parent directory containing a .mvn subdirectory or a pom.xml flagged with the root="true" attribute. If no such directory can be found, accessing the rootDirectory property will throw an IllegalStateException.
* session.topDirectory : the directory of the topmost project being built, usually the current directory or the directory pointed at by the -f/--file command line argument. The topDirectory is similar to the executionRootDirectory property available on the session, but renamed to make it coherent with the new rootDirectory and to avoid using root in its name. The topDirectory property is computed by the CLI as the directory pointed at by the -f/--file command line argument, or the current directory if there's no such argument.
* session.rootDirectory : the rootDirectory for the topDirectory project.
The topDirectory and rootDirectory properties are made available on the MavenSession / Session and deprecate the executionRootDirectory and multiModuleProjectDirectory properties. The rootDirectory should never change for a given project and is thus made available for profile activation and model interpolation (without the project. prefix, similar to basedir). The goal is also to make the rootDirectory property also available during command line arguments interpolation.
A root boolean attribute is also added to the model to indicate that the project is the root project. This attribute is only supported if the buildconsumer feature is active and removed before the pom is installed or deployed. It can be used as an alternative mechanism to the .mvn directory.
This is the port of https://github.com/apache/maven/pull/1075 to the master branch.
The good thing is that this is ONLY the tests because the maven 4 does not have the problem of MNG-7750.
A few small changes in the tests were needed to handle the internal differences between maven 3.x and maven 4.x.
---
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
* [MNG-6825] Replace FileUtils with Commons IO
Co-authored-by: Moderne <team@moderne.io>
* Minor fixes and reverts where cases are not handled yet
* Drop explicit dependencies on plexus-utils
---------
Co-authored-by: Moderne <team@moderne.io>
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
Guillaume Nodet
Slawomir Jaranowski
huazhongming
Tamas Cservenak
Karl Heinz Marbaise
Hervé Boutemy
Henning Schmiedehausen
huazhongming
Petr Široký
Tim te Beek
Giovanni van der Schelde
Niels Basjes
Tim te Beek
Elliotte Rusty Harold
Andrey Bruykhov
Christoph Läubrich
Alexey Venderov
Pavel Horal
Michael Osipov
Konrad Windszus
Olivier Lamy
Simon
Abdel Hajou