Description: the spring-boot.run.jvmArguments does not take precedence over the < systemPropertyVariables> map when there is a <jvmArguments> section defined for the spring-boot-maven-plugin.

Documented behavior: According to the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/run-system-properties.html when the spring-boot.run.jvmArguments parameter is provided for the spring-boot:run command the parameter takes precedence and overwrites the system properties defined within the <systemPropertyVariables> XML configuration. I would expect that the presence of the jvmArguments section does not influence the documented behavior.

Steps to reproduce: There is a sample application which demonstrates non-documented (faulty?) behavior located at https://github.com/rawfg/maven-jvmargs.

  1. The sample application prints the system properties starting with the xyz and by default there are two system properties configured: one comes from the <jvmArguments> section and the other one comes from the < systemPropertyVariables> section.

  2. When the application is run from the command line via the command:

mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dxyz.MavenSystemProperty='cmd-system-property'" 

the output is (system properties configured in the pom.xml):

xyz.MavenSystemProperty=maven-system-property
xyz.MavenJvmProperty=maven-jvm-property
  1. When the <jvmArguments> section is commented out the application behaves as it was documented, so running the command:
mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dxyz.MavenSystemProperty='cmd-system-property'" 

results in the output:

xyz.MavenSystemProperty=cmd-system-property
  1. I tested it with the Spring Boot version 2.2.4 but I've downgraded to the 2.1.7 version and I observed the same outcome.

Expected behavior: - -Dspring-boot.run.jvmArguments always works as documented (step 3) or - the exception is documented in the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/run-system-properties.html

Comment From: scottfrederick

A value provided by <jvmArguments> in the POM configuration takes precedence over a value provided by the spring-boot.run.jvmArguments system property. So in the case of your sample app as provided without changes, the -Dspring-boot.run.jvmArguments=-Dxyz.MavenSystemProperty=cmd-system-property will be ignored. When the <jvmArguments> POM configuration is removed, then the spring-boot.run.jvmArguments value is used.

Expected behavior: * -Dspring-boot.run.jvmArguments always works as documented (step 3) or * the exception is documented in the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/run-system-properties.html

This isn't so much an exception as it is an order of precedence. The documentation states that jvmArguments takes precedence over <systemPropertyVariables>, which is always the case. What isn't documented is which manner of providing jvmArguments takes precedence. A quick test shows that the order of precedence isn't consistent between configuration properties like jvmArguments and arguments.

I've marked this for team attention so we can discuss the proper order of precedence between POM configuration and spring-boot.run system properties, adding tests to confirm the proper behavior, and documenting the behavior.

Comment From: wilkinsona

For consistency with configuration precedence in other area of Spring Boot, I think that system properties provided on the command line should take precedence over something that's hardcoded in the pom.xml file.

Comment From: scottfrederick

Maven documents the fact that Mojo @Parameters can be set via POM configuration or from system properties (provided the @Parameter has a property attribute) but I can't find the order of precedence documented anywhere. However, testing shows that POM configuration takes precedence over system properties.

spring-boot.run.arguments is the exception to the rule because Boot's Mojo reverses the default Maven order by declaring two separate parameters and resolving them explicitly.

Comment From: wilkinsona

However, testing shows that POM configuration takes precedence over system properties.

Just to make sure I've understood, that's the opposite of what would align with Boot's configuration precedence in other areas?

Comment From: scottfrederick

Just to make sure I've understood, that's the opposite of what would align with Boot's configuration precedence in other areas?

Yes, exactly the opposite.

Comment From: wilkinsona

We're going to align with Maven's defaults.

Comment From: wilkinsona

Re-opening so that we can investigate the test failures on Windows: https://ge.spring.io/s/m62r4fmeh6y6k/tests/failed.

Comment From: wilkinsona

2.2.x is unaffected by the test failures.