Multi-mod Maven case doesn't allow launch from "child" directory using mvnw wrapper from parent

[scottkurz]

PROBLEM

Say I have a multi-mod Maven structure like:

parent
 + pom.xml
 + mvnw
 + war
      + pom.xml
      + src/main/liberty/config/server.xml
      ....
 + jar
      pom.xml
      ...

In Liberty Tools Eclipse, I can run from the parent project and use the default parms (which is an empty list) and get mvnw liberty:dev, i.e. it'll use the mvnw wrapper in the root.

However, if I try to run from the 'war' level, I'll get default parms of ( ... -f ../pom.xml -pl war). However there's no way to pick up mvnw.

IDEA

• Can we try to look for 'mvnw' in the parent/containing folder?
• Should we only do such a check if we see a relative path like ../pom.xml as the -f parm value?
• Does this steer us towards the need of a display of the full generated command? : https://github.com/OpenLiberty/liberty-tools-eclipse/issues/210

[scottkurz]

I think we can either:

1. Relax and extend our "custom parameters" parsing to allow the user to type something that resolves to mvn or mvnw, OR:
2. Extend our algorithm which provides the Maven executable to look for a parent wrapper and use it.

So for 1. we could allow:
../mvnw ...rest of parms

For 2., the algorithm would be like:

a. Look for mvnw in immediate dir b. Look for mvnw in parent dir (possibly recursively walking up the chain) c. Look for mvn in preferences d. Find mvn via PATH

I like 2., I think it's simpler for the user... they're not really trying to achieve some unique custom behavior, just to use the wrapper they have, and we avoid having to get it right detecting "is this a mvn executable?"

[scottkurz]

We like 2., but what if the parent (in 2b.) is a containing directory but not an actual "parent"? Consider further before implementing. How does this apply to VSCode and IDEA if those use more single project rather than a single workspace.