[MNG-8211] Maven should fail builds that use CI Friendly versions but have no values set

[jira-importer]

Tamas Cservenak opened MNG-8211 and commented

As otherwise it is just source of confusion, Maven will "happily" install and deploy artifacts as G:A:$revision and this is 100% NOT what users wants.
Still, to not be disruptive, the old behaviour can be achieved by setting maven.build.allowExpressionInEffectiveProjectVersion=true project property.

---

Issue Links:

• MINSTALL-202 Version property is not expanded for destination path

Remote Links:

• GitHub Pull Request #1656
  
• GitHub Pull Request #1673
  

Backported to: 4.0.0-beta-4, 3.9.10

[jira-importer]

Slawomir Jaranowski commented

What with case when user want to prepare value for revision property by another plugin during execution?

Like in: https://www.mojohaus.org/versions/versions-maven-plugin/use-dynamic-version-from-scm-mojo.html
goal set revision dynamically based on scm info

[jira-importer]

Tamas Cservenak commented

sjaranowski That use case ("prepare value by a plugin") is violation of CI Friendly Versions as documented here: https://maven.apache.org/maven-ci-friendly.html

The documentation clearly states that property MUST exists (either in project properties or in user properties set with CLI -Dxxx=xxx or maven.config).

But in essence, what happens: when Maven session starts, after effective models are built, it is too late for any plugin to kick in, set a property, whatever, as in memory effective model will still have project.version=${prop} in place. Whatever any plugin does later, it does NOT change effective model, and just like in in MINSTALL-202 misunderstanding, it is NOT the job of m-install-p to "interpolate" the version! If that would be so, EVERY PLUGIN would need to re-evaluate effective model at every mojo execution as any previous plugin could injected some new property, and this is NOT how Maven works.

(note that current "CI Friendly" implementation still does not do anything with POM file, hence when you use it, you cannot use simple install/deploy plugins, but you must "rewrite" the POM file also as documented using flatten or some alike plugin!)

The CI Friendly documentation clearly states: the property must be available beforehand: either as project property or as user property.

[jira-importer]

Tamas Cservenak commented

The limitation of "setting property" is clearly explained for example here: https://www.mojohaus.org/properties-maven-plugin/#plugin-limitations newly added properties by plugin are only available for other (downstream) plugins like m-resource-p for filtering resources.

Also, Nisse tries to explain this as well: https://github.com/maveniverse/nisse

• nisse plugin "just makes properties available for other plugins"
• nisse extension "makes properties available as user properties (as user would type them -Dxxx=xx) and also inlines POM file as well, hence plain install/deploy works as well". But this is doable ONLY from an extension.

[jira-importer]

Tamas Cservenak commented

In short: we deal with two things here: in memory "effective model" that is built, and the POM file from the disk (used to build "effective model"). Important thing to understand, is that these two are "disconnected", in a way, once effective model is built, and possibly altered (like with injection of user property for version), the original POM file remains unchanged!

The existing "CI friendly versions" feature allows dynamic versions to be injected into version (so, allows property in place of project.version) but it did not validate that replacement did happen! This is alleviated by this issue, as many times users deployed something that had version ${revision} and was only a source of confusion for them. Also, CI friendly versions documentation clearly states that such deployed things are unusable by other projects. Hence, in 99.9% we can say this is NOT what users wanted to deploy. Hence, IMHO Maven should fail the build if dynamic version injection did not happen (due any reason).