If property `java.version` is in unexpected format, the activator throws `NumberFormatEx`, that in turn, is caught and reported by `DefaultProfileSelector` w/o any cause.
These should be cleanly reported instead: report that `java.version` property is in "unexpected format", and also report why was there are failure to evaluate a property activation.
Note 1: Maven allows `-Djava.version` override (!!!), this is exactly what IT MNG-3746 does, but the `NumberFormatEx` went unnoticed, was swallowed, no cause reported.
Note 2: This bug was revealed by #1555 as it reported the issue, and later "asserted error free log" which was not error-free. Hence, this bug was simply revealed by improved logging on unrelated issue.
---
https://issues.apache.org/jira/browse/MNG-8142
This commit aims to complete d075fe7e85, which moved `ModelVersionParser`
interface from the `org.apache.maven.model.version` package to `org.apache.maven.api.services.model`.
Completing this change is necessary for building `maven-plugin-tools` or `maven-plugin-testing`.
This commit deletes the old interface for making sure that there is no accidental use.
The old and new interfaces were identical except for the package names and the imports.
As a result of this change, the following implementation classes are identical except
for package names and imports:
* `maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelVersionParser.java`
* `maven-api-impl/src/main/java/org/apache/maven/internal/impl/DefaultModelVersionParser.java`
* Javadoc cleanup and replacement of some `System.getProperty("...")` by more specific standard methods.
* Add Type.PROCESSOR, MODULAR_PROCESSOR and CLASSPATH_PROCESSOR.
* Modification of the path type API:
* Add a `warningForFilenameBasedAutomodules()` method in `DependencyResolverResult`.
* Add relationships from `JavaPathType` to `javax.tool` location API.
* Modify the `PathType.option(Iterable<? extends Path>)` return type
because the option and the value need to be two separated arguments.
* Fixes according some comments on the pull request.
Make execution flow never invoke path.toFile, at least what model-builder and maven-resolver-provider matters. Using new methods from Resolver 2 alpha8 and also adding in relevant maven bits, as half of the work was already done.
---
https://issues.apache.org/jira/browse/MNG-8059
The artificial (or "bolted on") scope "import" behaves wildly differently that rest of Maven, causes surprise to our users. For start, we should emit "actionable" warnings about these, ultimate goal is to align this behaviour with "maven way" of working ("closest occurence wins" vs current weird "direct occurrence then first occurence wins" strategy).
Warnings are only created when the dependency is not directly managed. The warning also suggests to add a direct managed dependency to get rid of it, so it's now helpful and actionnable.
---
https://issues.apache.org/jira/browse/MNG-7854
As it is actually not needed. This also "pulls in" all of VersionParser into model version parser, so Core implementation now 100% just delegates over there.
---
https://issues.apache.org/jira/browse/MNG-7978
Update to Resolver alpha-5 and apply some cleanups.
Notable changes:
* update resolver to 2.0.0-alpha-5
* detach model-builder from maven-artifact (this is important)
* introduce model builder own VersionParser iface (implemented in resolver-provider)
* API VersionParser implementation reuses VersionParser from resolver-provider to implement the service
* various other cleanups, removal of old plexus, etc
---
https://issues.apache.org/jira/browse/MNG-7974
* [MNG-7963] Clean up the build
Changes:
* remove hamcrest 1.3 from scope
* set proc:none to prevent warnings (Sisu APT is on classpath),
we do not use annotation processing, we produce Sisu index
explicitly.
* remove some redundant elements from POMs
* Add an InternalSession interface to avoid casting to the implementation in various places
* Upgrade to Guice 6.0.0 and add support for jakarta.inject annotations
* Maven 4 Plugin API
Tamas Cservenak
Michael Keppler
liutang123
Guillaume Nodet
Martin Desruisseaux
Konrad Windszus
Matt Benson
Slawomir Jaranowski
huazhongming
Hervé Boutemy