Support in dev/devc for multiple independent WAR/EAR modules

[ulisse1996]

Right now liberty plug-in only supports a multi module maven project with an ear for multiple wars or a single war deploy in dev/devc module. Requested feature make also possible to create a multi maven project with following structure :

• War A
  • Jar F
  • Jar G
• War B
  • Jar F
• Ear C
  • War D
  • War E
  • Jar F

Using only an instance of liberty server defined in parent pom or designed configuration dependency

[yeekangc]

Where War A, War B and Ear C are meant to be deployed on the same instance of Liberty, @ulisse1996? Thanks.

[ulisse1996]

@yeekangc With the current version of dev/devc mode, you can only create a multi module maven project with an ear package (multiple wars/jars dependecies) or a war package (multiple jars dependencies) with only one independent module.

Requested feature is to make also possibile to auto build, deploy and hot swap code using a maven reactor tree like the one in previous comment, so Liberty Tools Plugin will manage multiple ear/war packages in the same multi module project

[scottkurz]

Hi @ulisse1996 thank you for opening the issue here.

We were just reviewing our enhancement backlog.

I actually think you could achieve something like this today if you followed the pattern used in this integration test project: https://github.com/OpenLiberty/ci.maven/tree/main/liberty-maven-plugin/src/it/dev-it/resources/multi-module-projects/typeJ

I understand this gets into less obvious liberty-maven-plugin configuration, so you might not have thought to try this.

But basically within the reactor/multi-module project you have one module, ....../typeJ/pom/pom.xml whose build is configured with the liberty-maven-plugin.

This 'pom' module also:

• uses a 'pom' packaging type
• includes the server config (src/main/liberty/config/server.xml, etc.)
• declares dependencies on the relevant application modules (in this case, war1 and war2)
• uses liberty-maven-plugin configuration of <deployPackages>dependencies</deployPackages> (see deploy doc).

I think if you try to follow this pattern you'll see you can indeed achieve a hot code replace behavior across >1 independent application module.

However, if you've tried this and it hasn't worked, can I ask what problem you're seeing with this?