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.
-
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. -
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
- 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
- I tested it with the Spring Boot version
2.2.4
but I've downgraded to the2.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 @Parameter
s 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.