<configuration> is missing a <skip> element for the codeserver goal

[groomble]

If one wanted to optionally run a codeserver (with a command line switch), perhaps for development purposes, on build, there is no way to do it except for specifying it as gwt:codeserver. However, for projects with multiple Maven modules, this results in the gwt:codeserver goal being run against every Maven module. This leads to an error and an exit because the root project is frequently empty, and not all Maven modules necessarily produce GWT modules. The gwt:codeserver goal cannot be run directly against the submodules because the multimodule 'reactor' dependency resolution mechanism fails when Maven is attempting to compile a single Maven submodule.

To solve this, I suggest a <skip> option is added to the <configuration> tag of the <execution> tag for the codeserver goal.

This will allow root (parent) pom.xml files to establish a property for controlling the codeserver's launch, which can them be set from the command line or through build profiles.

If you would like an example project which requires this addition to launch the codeserver, I can provide one.

[tbroyer]

gwt:codeserver (and gwt:devmode) are specifically designed to be called from the command-line on the root module of your multi-module build. If that errors out, then it might be that you need to configure the goal's modules and/or projects.

I don't understand your usecase (why would one use superdevmode rather than e.g. compiling in draft mode? when and how would the superdevmode server be stopped? etc.), but I believe the solution you're proposing is wrong. (to begin with, gwt:codeserver being an aggregator goal, it is not run against all modules in the reactor; it does fork a process-classes lifecycle for each reactor module though)

Could you share more details about what you're trying to do?

[groomble]

The specific setup I have is thus:
project (packing: POM)
|----project-client (gwt-app)
|----project-server (war)
|----project-core (gwt-lib, but I'll likely switch to jar with sources later)
|----project-war (war with overlays to combine client and server into a single war)

In a perfect world, I would run gwt:codeserver on project. However, when I do so, I receive errors like:
Finding entry point classes
[INFO] Tracing compile failure path for type 'com.groomble.project.client.PrimaryScreen'
[INFO] [ERROR] Errors in 'file:/home/user/workspace_neon_b/project/project-client/src/main/java/com/groomble/project/client/PrimaryScreen.java'
[INFO] [ERROR] Line 27: No source code is available for type com.groomble.project.core.Schedule.ResourceListener; did you forget to inherit a required module?
[INFO] [ERROR] Line 32: No source code is available for type com.groomble.project.core.Resource; did you forget to inherit a required module?
[INFO] [ERROR] Line 27: No source code is available for type com.groomble.project.core.Schedule.TaskListener; did you forget to inherit a required module?
[INFO] [ERROR] Line 29: No source code is available for type com.groomble.project.core.Schedule; did you forget to inherit a required module?
[INFO] [ERROR] Line 34: No source code is available for type com.groomble.project.core.Task; did you forget to inherit a required module?

I have also received errors for the server component (for obvious reasons, attempts to find a GWT module fail) and the war module (no java source, and no module) when attempting to make this compile. To permit the normal workflow, I set up the pom for project-client to check for a property, and conditionally run the codeserver goal in the packaging phase. This permits both a normal compilation (by not setting the property) and a codeserver run which can find dependencies and does not error out on other submodules. Unfortunately, the way I had to do this was by making the property default to add-super-resources then set it to codeserver to run the codeserver. The property is then fed into the <goal> element of the <execution> tag bound to the packaging phase. This produces the behavior I need (ability to optionally run a gwt:codeserver on the multimodule project), but the solution I put together is a little unwieldy (it relies on add-super-resources being effectively a no-op) and it's hardly intuitive.

[tbroyer]

I suspect that your project-client's dependency on project-core does not have <type>gwt-lib</type>, so the module's sources aren't passed to the CodeServer. If that's the case, when you run Maven with debug logs (mvn -X gwt:codeserver), you should see a log line like:

[DEBUG] Ignoring com.groomble.project:project-core:1.0-SNAPSHOT; neither a gwt-lib or jar:sources.

In #86 I wondered if I shouldn't change the log level from DEBUG to INFO. What do you think?

[nfekete]

For a one-line message/module I think it's definitely worth lifting up the log level.

[groomble]

Having tried<type>gwt-lib</type>, I can confirm it solves the error. Thanks!

And yes, I think that seeing the error at INFO (or even higher) would be helpful.