enable build with Maven 4

[hboutemy]

[INFO] -------------------------------------------------
[INFO] Build Summary:
[INFO]   Passed: 32, Failed: 1, Errors: 0, Skipped: 2
[INFO] -------------------------------------------------
Error:  The following builds failed:
Error:  *  effective-pom_properties/pom.xml
[INFO] -------------------------------------------------

[hboutemy]

give it fails, this PR is not yet ready for merging: we need to fix Maven 4.0.0-SNAPSHOT first and release RC6

[Bukama]

Apache Maven 4.0.0-rc-5 (fb3ecaef88106acb40467a450248dfdbd75f3b35)
Maven home: C:\apache-maven-4.0.0-rc-5
Java version: 25.0.2, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-25
Default locale: de_DE, platform encoding: UTF-8
OS name: "windows 11", version: "10.0", arch: "amd64", family: "winnt"

[INFO] Build Summary:
[INFO]   Passed: 32, Failed: 1, Errors: 0, Skipped: 2
[INFO] -------------------------------------------------
[ERROR] The following builds failed:
[ERROR] *  effective-pom_properties\pom.xml
[INFO] -------------------------------------------------
[WARNING] The following builds were skipped:
[WARNING] *  evaluate-forceStdout\pom.xml
[WARNING] *  evaluate-settings-servers\pom.xml

I think the failing tests has to do with the line seperators as they dont get escaped in the regex and therefore do not match the expected output. The foollowing is listed in the output

<properties>\r\n    <maven.compiler.target>1.6</maven.compiler.target>\r\n    <maven.compiler.source>1.6</maven.compiler.source>\r\n    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>\r\n    <project.build.outputTimestamp>1980-02-01T00:00:00Z</project.build.outputTimestamp>\r\n    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>\r\n  </properties>

I'm not sure if we care about the line breaks, but if we only compare about the comparision of the two properties than we could change the test to

String content = new File( basedir, "build.log" ).text
assert content.exists()
assert content.contains( "<maven.compiler.target>1.6</maven.compiler.target>" )
assert content.contains( "<maven.compiler.source>1.6</maven.compiler.source>" )

This would also make the test independent of the order of the properties.

[hboutemy]

rebuild after #366

[hboutemy]

I don't get https://github.com/apache/maven-help-plugin/pull/344/changes#diff-7b81cfece99ab40b32e3d95307f758917927d80a77fc3ab06f6fd057ac7d5318
// Maven 4 take precedence over the pom properties: why are the properties value 1.6 expected to be replaced by 8?

[cstamas]

re 4: when stdout comes to play, you MUST use --raw-streams, as Maven 4 is more like mvnd is, than Maven 3 (this option was initially introduced with mvnd). Later we did this: apache/maven#2361 (see related JIRA). So from 3.9.10, the --raw-streams is supported as well (as nop).

[hboutemy]

@cstamas sorry, I don't get how this is related to the current issue (nor what concretely to do in this PR): can you explain one and/or the other, please?

[Bukama]

// Maven 4 take precedence over the pom properties: why are the properties value 1.6 expected to be replaced by 8?

Just writing down thoughts of a layman:
I could image that it is some kind of "auto-fix", because Maven 4 requires JDK 17, which can only compile against Java 7+ and not 6 anymore. My personal guess 8 is then taken as a default compatibilty for Maven 3, which requires 8.
However ofc only when no toolchain is in place, which could compile against any other JDK

re 4: when stdout comes to play, you MUST use --raw-streams

AI says

The --raw-streams option in the [⁠Maven Daemon (mvnd)](https://github.com/apache/maven-mvnd) prevents the daemon from applying decorative/interactive formatting to the console logs. It forces mvnd to output the raw, unadorned build stream directly to your console, similar to the standard mvn executable

So if I understand correctly mvnd and Maven 3.10+ do format logs in another way than 3.9.x does. Do get the same output in the build.log. With the raw-stream option the issue I mentioned about formatting should be fixed. However the different order of properties comes from the first.