The mojos in the Maven plugin use inheritance in their implementations. This has created some problems with how those goals and their parameters are documented:

  1. Some parameters have user properties that do not match the goal's name. For example, the commandLineArguments parameter of the start goal can be specified on the command line using spring-boot.run.arguments. I think it should be spring-boot.start.arguments.
  2. Some parameters have properties with an incorrect since version. For example, the start goal was added in 1.3.0 but its directories parameter is documented as being since 1.0.0
  3. Some parameters have descriptions that aren't quite right. For example, the addResources parameter of the start goals says to "consider adding spring-boot-devtools to your project instead". I'm not sure that's good advice for starting an app for integration testing.

I think we need to move away from inheriting @Parameter fields. Doing so would allow each mojo to accurately describe each parameter in the context of the mojo's intended usage. We may want to have each mojo declaring all of its own parameters and then, when execute is called, create an instance of a shared class that knows how to run/start an application that can be configured using the parameters.

Unfortunately, I'm not sure how we can completely straighten this out in a backwards compatible manner. If we fix problem 1 above, spring-boot.run.arguments would no longer affect the command line arguments of the start goal and you'd have to use spring-boot.start.arguments instead unless we somehow fell back to spring-boot.run.arguments if spring-boot.start.arguments has not been specified.

Comment From: wilkinsona

Chatting with @snicoll, we think we can address the problems with the parameter descriptions and since information in 2.7.x as the changes would be backwards-compatible. Then, in a 3.x release, we can review the properties and their names deciding which we want to keep and what their new names should be.

Comment From: wilkinsona

Looking at this again, I don't see how it can be done elegantly in a way that's backwards compatible. The descriptions and since information is read from the annotations and javadoc on the @Parameter fields. To correct it, we'd need to move all of those fields from the abstract classes into each concrete sub-class. We'd then have to somehow make the values of those fields available to the super-classes. This would be quite an extensive change for a maintenance release. Furthermore, to preserve backwards compatibility we'd have to keep the incorrect property attributes. For example, we'd have @Parameter(property = "spring-boot.run.jvmArguments") on the jvmArguments field of StartMojo. All in all, I think the cure's going to be worse than the disease and we should leave things as they are.