Maven plugin (spring-boot:run) should take list for JVM arguments

[alan-czajkowski]

Problem: It is too easy to break spring-boot:run by passing in garbage in the <jvmArguments> configuration. Currently it looks like this (not a list):

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <jvmArguments>any kind of garbage</jvmArguments>
  </configuration>
</plugin>

Solution: The Maven plugin should allow passing in Java (JVM) system properties via some kind of list definition in XML.

Example solution:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <jvmArguments>
      <options>
        <option>-Xms512m</option>
        <option>-Xmx1024m</option>
      </options>
      <systemProperties>
        <systemProperty>systemProperty1=value1</systemProperty>
        <systemProperty>systemProperty2=value2</systemProperty>
      </systemProperties>
    </jvmArguments>
  </configuration>
</plugin>

where each <option> is passed in as-is to the JVM, and each <systemProperty> is pre-pended with a -D:

-Xms512m -Xmx1024m -DsystemProperty1=value1 -DsystemProperty2=value2

[andrew-j-cohen]

I think that's a good idea. Just one suggestion - to eliminate the possibility of someone forgetting the "=" in the system property, perhaps systemProperty can look something like this:

<systemProperty>
    <key>systemProperty1</key>
    <value>value1</value>
<systemProperty>

I'm happy to work on a PR for this.

[snicoll]

I would go with what other plugins are doing. A quick look at a well know plugin in Maven land got me this and an example. @andrew-j-cohen if you're willing to give that a try, please go ahead. Thanks!

[alan-czajkowski]

@andrew-j-cohen @snicoll I agree that this is the best solution aesthetically:

<systemProperties>
  <systemProperty>
    <key>systemProperty1</key>
    <value>value1</value>
  </systemProperty>
</systemProperties>

but consider the case of system properties that have a key but no value, example:

-DpropertyWithNoValue -DpropertyWithValue=value

the XML would look something like this:

<systemProperties>
  <systemProperty>
    <key>propertyWithNoValue</key>
    <value></value>
  </systemProperty>
  <systemProperty>
    <key>propertyWithValue</key>
    <value>value</value>
  </systemProperty>
</systemProperties>

How would this render?

-DpropertyWithNoValue= -DpropertyWithValue=value

with a dangling equals sign on the first property?

I still think this is the best solution to cover all possible scenarios:

<systemProperties>
  <systemProperty>propertyWithNoValue</systemProperty>
  <systemProperty>propertyWithValue=value</systemProperty>
</systemProperties>

[alan-czajkowski]

FYI: don't forget that system property values can have spaces in them so you will have to pass them in safely as JVM arguments.
Example:

<systemProperties>
  <systemProperty>propertyWithNoValue</systemProperty>
  <systemProperty>propertyWithValue=value</systemProperty>
  <systemProperty>propertyWithValueContainingSpace=value has space</systemProperty>
</systemProperties>

should render safely, the equivalent of:

"-DpropertyWithNoValue" "-DpropertyWithValue=value" "-DpropertyWithValueContainingSpace=value has space"

[andrew-j-cohen]

@alan-czajkowski @snicoll Thank you both for your feedback. I will work on these improvements.

[wilkinsona]

@andrew-j-cohen Thanks. To avoid potentially wasted effort, I'd wait a bit till we've agreed on the format. FWIW, in the interests of consistency, I agree with @snicoll on following Surefire's lead.

[andrew-j-cohen]

I've done a bit more research and I concur with following Surefire's approach with respect to splitting out system properties from arbitrary JVM options (i.e., the "argLine" option). Note that the Surefire plugin does not prevent the user from putting in garbage (or making a typo) in the "argLine" property. However, Alan's suggested structured format for arbitrary JVM options wouldn't necessarily prevent someone from putting an invalid JVM argument in there either, so I don't think there is much to be gained with that more verbose format. Thoughts?

[wilkinsona]

@andrew-j-cohen Thanks for doing some additional research. Agreed that the more verbose format does provide much benefit. Unless @snicoll objects, let's go with a Surefire-inspired approach.

[alan-czajkowski]

@andrew-j-cohen the verbose format for JVM option is necessary because of the requirement to pass in each JVM option correctly and safely to the JVM.

Consider:

<argLine>-Xms512m -Xmx1024m followed by garbage</argLine>

What does this mean? What is the consequence of this? This is an important question. Because you don't care that there is garbage, what you care about is what is a distinct option and what is not. Does this mean:

$ java "-Xms512m -Xmx1024m followed by garbage" -jar ...

or does this mean:

$ java "-Xms512m" "-Xmx1024m" "followed" "by" "garbage" -jar ...

because these 2 results above mean 2 very different things to the JVM.
Note that you don't care whether garbage is passed in, you simply care that it is passed in correctly and safely. The only way to achieve correctness and safety is through something like:

<options>
  <option>-Xms512m</option>
  <option>-Xmx1024m</option>
</options>

The example below cannot achieve correctness, and can only achieve limited safety:

<argLine>-Xms512m -Xmx1024m followed by garbage</argLine>