Document that -Dspring.profiles.active should not be used to run an app with Maven

[mvitz]

Running my application via ./mvnw spring-boot:run -Dspring.profiles.active=dev works and activates the dev-Profile. However if I add spring-boot-devtools the specified profile is not used any longer.

An example showing this behaviour can be found at https://github.com/mvitz/maven-spring-boot-devtools-Dspring.profiles.active-bug

Best outcome would be that this will be fixed, if not possible it should at least be documented.

[wilkinsona]

As explained in the documentation, adding DevTools causes run to fork a separate JVM. You are passing the system property into Maven’s JVM so it isn’t picked up by the forked JVM used by the application. You should use run.profiles or run.jvmArguments instead.

[mvitz]

Thanks for your fast response and explanation.

Imho this could be made a little bit clearer in the documentation as not everyone is aware that spawning own processes implies that this JVM-Argument is swallowed but thats up to you.

Just as an explaination why I opened this:

Some members of a team I know used -Dspring.profiles.active in their run scripts and after someone added DevTools this scripts were broken and they refused to use DevTools. My hope was that having this behaviour documented clearer would have lead to fewer frustration.

Have a nice weekend & regards
Michael

[wilkinsona]

Ok, let’s see what we can do. Perhaps you or someone on your team could propose something that would have made the documentation clearer?

[snicoll]

There is also the idea of logging something to indicate that the JVM has been forked and variables set on the maven process won't be transmitted. I've shared some reservation on #16819 and flagging for team attention to see what the rest of the team thinks.

[drahkrub]

There is also the idea of logging something to indicate that the JVM has been forked

Logging is better than nothing, but I would prefer something on screen (if there is enough space for ascii art banners, then a one-liner should fit there as well ;-)).

[snicoll]

We've decided to revisit the documentation and change the default value of the fork property, see #16945