Forcing a user's command to always start with pre-pended "mvn/mvnw liberty:dev" is too inflexible, prevents running a goal before liberty:dev or overriding LMP version

Currently a Liberty Tools Eclipse can NOT achieve something like:

mvn resources:copy-resources liberty:dev
mvn io.openliberty.tools:liberty-maven-plugin:3.7.1:dev
gradle :ear:libertyDev

(Note in 3., there are currently other issues with EAR/multi-project loose apps in LGP, but leaving aside whether it will "work", I'm noting you can't even invoke such a command).

By adding the parameters typed by the user to the end of the command invocation: mvn io.openliberty.tools:liberty-maven-plugin:dev ...<typed parms>... we make impossible something like mvn some:goal liberty:dev .

We could either:

• allow for typing the full command (after mvn, including liberty:dev)
  • possibly being smart enough to look for a user-typed liberty:dev and only add one if we don't see one
• abandon this use case for m2e, or some other approach

RELATED

• This also prevents us overriding the LMP version via: mvn io.openliberty.tools:liberty-maven-plugin:3.7.2:dev ...
• Slightly unrelated topic but what about allowing the user to type 'mvn' to override the use of the 'mvnw' wrapper. Could this be a good thing?

UPDATED PROPOSAL

• Parse the command line and look for an existing dev goal/task
  • If one is detected, don't add the dev goal/task to the generated command

However, we reject the idea of allowing an override of mvn vs. mvnw.

Start by locating where Liberty Tools Eclipse constructs the Maven and Gradle command lines, then trace how user-typed parameters are appended. Implement the updated proposal so an existing Liberty dev goal or task is detected and not duplicated, while retaining the decision not to allow mvn versus mvnw overrides; verify the affected command-generation behavior with the project's tests.