There are logically two new fields here (final names TBD):
Aggregator (or "top-level", or "root") module home
Liberty server module
We map 1. to the working directory and the pom.xml of the invocation, and we map 2. to the -pl <module> value.
DESIGN
When an aggregate module is selected, it itself should be defaulted as the value of 1. The value of 2. can be blank, which means we will delegate to liberty-maven-plugin to figure out where dev mode should run.
When a aggregated (sub)module is selected, we use the aggregation model to determine the aggregator module, which we default to be the value of 1., and the value of 2. will be set to the selected module itself.
Note we do NOT at this point commit to disallowing or filtering out non-server modules, whether because they are JAR packaging types or even WAR packaging types that are not suitable for some reason.
In Eclipse, we already persist custom values (parms) set on the run configuration. For IDEA and VSCode, we should make sure we do this too.
OTHER NOTES
Note there might also be a need/desire to subclass the Gradle vs. Maven Run config control here, to only show the multi-module components in the Maven one.
Though it could also be desirable to only show this for projects we calculate to be Maven multi-module projects, we might still want to include the fields for ANY Maven multi-module, so that they can reference other projects in the OS filesystem, not just workspace projects.
There are logically two new fields here (final names TBD):
We map 1. to the working directory and the pom.xml of the invocation, and we map 2. to the
-pl <module>value.DESIGN
When an aggregate module is selected, it itself should be defaulted as the value of 1. The value of 2. can be blank, which means we will delegate to liberty-maven-plugin to figure out where dev mode should run.
When a aggregated (sub)module is selected, we use the aggregation model to determine the aggregator module, which we default to be the value of 1., and the value of 2. will be set to the selected module itself.
Note we do NOT at this point commit to disallowing or filtering out non-server modules, whether because they are JAR packaging types or even WAR packaging types that are not suitable for some reason.
In Eclipse, we already persist custom values (parms) set on the run configuration. For IDEA and VSCode, we should make sure we do this too.
OTHER NOTES
Note there might also be a need/desire to subclass the Gradle vs. Maven Run config control here, to only show the multi-module components in the Maven one.
Though it could also be desirable to only show this for projects we calculate to be Maven multi-module projects, we might still want to include the fields for ANY Maven multi-module, so that they can reference other projects in the OS filesystem, not just workspace projects.