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
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
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
Both plugin and regular repository should have the same policy.
Unfortunately using "never" is not possible as long as resolver applies
this policy to both artifacts (immutable) and metadata (mutable)
Improve DefaultModelValidator.compareModelVersions to be able to compare
versions which different numbers of segments, allowing it to compare
"4", "4.0", and "4.0.0" to each other for example.
Signed-off-by: Craig Andrews <candrews@integralblue.com>
This is ONLY the reproduction of the problem I found.
If you disable the activeProfile (in buildPom and remove the assert) then all checks pass.
If you enable this profile (provided code) then in several places the ${project.basedir} has been interpolated and shows the path of the build and the assertions fail the build.
---
https://issues.apache.org/jira/browse/MNG-7750
Tamas Cservenak
Slawomir Jaranowski
Dr. Christian Kohlschütter
Slawomir Jaranowski
Matt Benson
Konrad Windszus
Hervé Boutemy
Craig Andrews
Niels Basjes
Andrey Bruykhov