Per-module launcherDir using gwt-maven-plugin

[Sébastien]

Hi group,

We've a pretty large multimodule projet which delivers two wars with different server code. One of the war includes 3 gwt apps and the other one 1 gwt app (4 applications total).

I was wondering if there was a way to configure a separate launcherDir for the fourth application. Given the fact that it's done in root pom I'm assuming I'll have to rely on properties but if there's a better way I'd be happy to use it

By the way, passing -DLauncherDir on the CLI does not seem to have any effect on the generated command line

Kind regards

[Thomas Broyer]

On Monday, April 13, 2026 at 1:58:41 PM UTC+2 beussl...@gmail.com wrote:

Hi group,

We've a pretty large multimodule projet which delivers two wars with different server code. One of the war includes 3 gwt apps and the other one 1 gwt app (4 applications total).

I was wondering if there was a way to configure a separate launcherDir for the fourth application. Given the fact that it's done in root pom I'm assuming I'll have to rely on properties but if there's a better way I'd be happy to use it

I think I would declare 2 <execution>s (one of them could use the default-cli executionId), each with its own <launcherDir>, and either <modules> or <projects>, and then run "mvn gwt:codeserver@foo" and "mvn gwt:codeserver@bar"

 

By the way, passing -DLauncherDir on the CLI does not seem to have any effect on the generated command line

Besides that it's -DlauncherDir rather than -DLauncherDir (lowercase L), that can only work if you do not have a <launcherDir> configured in your POM. You should be able to experiment with the above by removing most configuration in the root POM and then running "mvn gwt:codeserver -DlauncherDir=… -Dgwt.projects=…"

[Sébastien]

Hi Thomas

Thank you for your hint, there was indeed a launcherDir in the root pom.xml (the -DLauncherDir was a typo in the message, not in the commande). Using -DlauncherDir works perfectly. I think I'll rely on properties with provided scripts to launch codeServer rather then execuitonsIds since this does the jobs and does not involve some strange Voodoo tricks :-)

Also I've a question wrt plugin usage, it looks like if I've A → B → C dependencies with A & B being gwt-lib-packaged and C gwt-app, I have to declare A as regular and classifier:sources dependency in B in order for A to be correctly picked up when launching codeServer on C, using <type>gwt-lib</type> on transitive dependencies does not seem to work as sources are not found. Did I, again, miss something?

Kind regards

[Thomas Broyer]

On Tuesday, April 14, 2026 at 10:18:49 AM UTC+2 beussl...@gmail.com wrote:

Also I've a question wrt plugin usage, it looks like if I've A → B → C dependencies with A & B being gwt-lib-packaged and C gwt-app, I have to declare A as regular and classifier:sources dependency in B in order for A to be correctly picked up when launching codeServer on C, using <type>gwt-lib</type> on transitive dependencies does not seem to work as sources are not found. Did I, again, miss something?

AFAIR, this should work.

It seems to work within the https://github.com/tbroyer/gwt-maven-plugin/tree/main/src/it/e2e integration test (clone the repo, checkout the 1.2.0 tag, run mvn clean verify, go to target/it-tests/e2e, run mvn gwt:codeserver -X, notice that it does print some ignored dependencies –due to the way projects are setup, but this might also not trigger the issue–, but the -src in the arguments are OK, then call http://127.0.0.1:9876/recompile/e2e?user.agent=safari to trigger a compilation and all goes well; this can be checked by opening http://127.0.0.1:9876/e2e/ in a browser)

Can you create a repro and open an issue?

(feel free to use the e2e integration test as a starting point, at least regarding the Java/GWT code)