Dev container mode issues

Background

Running libertyDevc in a multi-module project — where several submodules each have their own Liberty server configured — exposes three separate defects that together make it impossible to start more than one module in container dev mode on the same machine. They share the same scenario and the same root area in DevUtil.java, so they are tracked together.

Scenario used to reproduce all three
Project myApp has three independently Liberty-configured submodules (A, B, C), each with its own Dockerfile:

myApp/
  A/  build.gradle (or pom.xml)   Dockerfile
  B/  build.gradle (or pom.xml)   Dockerfile
  C/  build.gradle (or pom.xml)   Dockerfile
  settings.gradle (or pom.xml)

Starting each module in a separate terminal:

# Gradle
gradle :A:libertyDevc
gradle :B:libertyDevc
gradle :C:libertyDevc

# Maven
mvn liberty:devc -pl :A -am
mvn liberty:devc -pl :B -am
mvn liberty:devc -pl :C -am

Issue 1 :- Container name collision — all modules default to "liberty-dev"

Affects: Maven + Gradle

Actual behaviour

Starting a second module fails immediately. Both modules attempt to use the same default container name "liberty-dev", causing the container engine to reject the second:

Error: creating container storage: the container
name "liberty-dev" is already in use by
d7b017a907bd...

You have to remove that container to be able
to reuse that name.
Only one Liberty module can run in container dev mode at a time.

Expected behaviour

Each module automatically receives a unique, stable container name that does not conflict with other modules running on the same machine — with no manual configuration required from the user.

Issue 2:- Host port collision when multiple modules start simultaneously

Affects: Maven + Gradle

Actual behaviour

Two or more modules select the same host port for HTTP or HTTPS. The second container to bind the port fails:

A: podman run -p 9081:9080 -p 9444:9443 ...  ✓
B: podman run -p 9080:9080 -p 9443:9443 ...  ✓
C: podman run -p 9080:9080 -p 9443:9443 ...  ✗

Error: cannot bind tcp port :9080:
address already in use

Expected behaviour

Each module is automatically assigned distinct, non-conflicting host ports for HTTP and HTTPS — even when all modules are started at the same time.

Issue 3 :- Default Containerfile/Dockerfile resolved against the root directory instead of the submodule directory

Affects: Gradle only · Maven works correctly

Actual behaviour

• Running gradle :A:libertyDevc without an explicit --containerfile fails even though myApp/A/Dockerfile exists.
• The plugin searches the root project directory instead:
• No Containerfile or Dockerfile was found at /path/to/myApp/Dockerfile.
• Create a Containerfile/Dockerfile at the specified location to use dev mode with container support.

The equivalent Maven command (mvn liberty:devc -pl :A -am) finds A/Dockerfile correctly.

Expected behaviour

When no explicit containerfile is provided, the plugin looks for Containerfile or Dockerfile in the submodule's own directory — consistent with Maven and with how all other per-module configuration is resolved.

Start by reading DevUtil.java and tracing the Gradle libertyDevc container-mode entry point; compare its containerfile resolution with the Maven behavior described in the issue. Reproduce the three-module scenario, then verify that container names, HTTP/HTTPS host ports, and default Containerfile/Dockerfile lookup are distinct and module-local without manual configuration.