The `FilteredProjectDependencyGraph` class fix for non-transitive case and an UT. Also contains some improvement in classes, making them immutable as intended.
---
https://issues.apache.org/jira/browse/MNG-8256
As this is almost always source of confusion. If feature is used and there is no proper value set, fail the build, as users for sure does not plan to deploy artifacts with version `${revision}` (or any expression in project.version).
Still, to not be disruptive, the old behaviour can be achieved by setting `maven.build.allowExpressionInEffectiveProjectVersion`=true project property.
---
https://issues.apache.org/jira/browse/MNG-8211
Restore of uninterpolated things did "too much", we need to restore activations only.
Maven4 is not affected, manually checked using reproducer.
---
https://issues.apache.org/jira/browse/MNG-8188
As they really can come from anywhere. In case of this issue even from some eliminated POM that was read while collecting dirty tree, and was later eliminated. So confusing for users.
---
https://issues.apache.org/jira/browse/MNG-8177
Just warn for now, we cannot go from builds-ok w/
3.9.8 to fails-the-build in 3.9.9. Warning
can raise awareness, and this pattern is bad as
it is, but users now become aware that they may
have rogue plugin.xml (just like maven-compat had).
The original bug is fixed (Maven deploys unrelated metadata).
Same change is to be ported to master as well.
---
https://issues.apache.org/jira/browse/MNG-8180
There was an NPE possibility when plugin.xml had no expected tags present.
Also: maven-compat has plugin.xml (!) w/o "name" tag, it NPEd and failed build. This was NOT picked up by CI as "rebuild itself" step does not install (just verify).
---
https://issues.apache.org/jira/browse/MNG-8180
Resolver handles transparently the repository metadata, and in case of plugins it peeks into META-INF/maven/plugin.xml of given artifact JAR to figure out needed metadata bits (prefix, name, etc).
But, this was done "blindly", while it is expected that GA of JAR artifact without classifier (requirement for maven plugins) and GA in embedded plugin metadata must be same.
Decision here is to fail hard, prevent this being installed and deployed, as this is most probably wrong (unsure what maven-indexer or even Sonatype search would do in this case).
---
https://issues.apache.org/jira/browse/MNG-8180
A call to context.getSystemProperties() may yield empty an empty map, or
one missing the desired key, which makes a subsequent call of
toLowerCase fail with a NullPointerException.
Fall-back to using Os.OS_NAME and similar properties.
---------
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
Fix and improvement in one PR as they are closely related.
First, this PR restores the ability (broken by MNG-8081) to calculate Profile activation for POMs with duplicate Profile ID.
Second, this PR improves UX by warning them about invalid models in their build.
The reproducer now looks like this:
https://gist.github.com/cstamas/165a610b233f4c03e381a0a2697903eb
Notice:
* WARNs issued about models (all Maven versions are mute about this)
* still, property `${javafx.platform}` properly evaluated just like in 3.9.6 (but not in 3.9.7)
* build succeeds (fails in 3.9.7)
---
https://issues.apache.org/jira/browse/MNG-8147https://issues.apache.org/jira/browse/MNG-8141
And not rely that model was validated, which is not true in some cases. Model builder can still easily detect issues with models while building them.
Provides "escape hatch" for projects stuck on invalid models in form of user property that can be enabled with `-Dmaven.modelBuilder.failOnInvalidModel=false`, this reverts to _old_ behaviour of maven, and the JavaFX reproducer goes back to error "unable to resolve" errors with uninterpolated `${javafx.platform}` property as classifier.
---
https://issues.apache.org/jira/browse/MNG-8141
The info is there, but we redirect user to rinse-repeat in debug mode, that that creates a TON of output.
All is there, just tell why.
---
https://issues.apache.org/jira/browse/MNG-8140
For start, keeping almost same LOC but the distro zip lost almost 1 MB (was 10MB now is 9MB). Second, am really unsure why it was introduced in the first place, as it merely caused confusion, over StringUtils for example.
---
https://issues.apache.org/jira/browse/MNG-8146
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
Tamas Cservenak
Slawomir Jaranowski
Dr. Christian Kohlschütter
Piotrek Żygieło
James Z.M. Gao
Slawomir Jaranowski
Pavlo Shevchenko
Yueh Chun Wu
Sylwester Lachiewicz
Matt Benson