Generation of source elements in module.gwt.xml for dependencies about gwt-maven-plugin

[tbroyer]

What do you mean by “source elements for the dependencies” ? Can you give an example of the output you'd like ?

[auke-]

Maybe i'm misusing the source elements in the module.gwt.xml and is the problem in the codeserver, but i'll try to explain the situation.

Assume i have the following projects, where <package> is the same for all projects:
<package>.lib-api
<package>.lib-widgets
<package>.lib-something
<package>.app-user
<package>.app-admin
<package>.app-other
<package>.engine

All projects have a module.gwt.xml with a source element (e.g. <source path="lib-api"/>). The lib- projects have gwt-lib packaging and the app- projects and the engine project have gwt-app packaging. The engine is able to load the other app- projects dynamically and doesn't depend on the other apps directly. The app- projects depend on one or more lib- projects and the generate-module goal adds them to the module.gwt.xml of the app- project.

When i use the codeserver goal one codeserver is started for all app- projects (and the engine project). The engine app loads the the appropriate app- dynamically (in the browser, by injecting a <project>.nocache.js script tag) and the codeserver compiles the app- projects code (and not the code for the other app- or lib- project, until they are requested). I think the code from any lib- dependency might be already compiled... i'm not sure, i often run a full mvn clean package before starting the codeserver).

The problem occurs when i change code in a lib- project and refresh the app- webapp (invoking the codeserver for the app- project). This results in stale files or an error in the codeserver. When i add the source path of the lib- project to the app- project, the problem disappears and the reloading seems to work.

So now i'm wondering:

• should i just add those <source path="..lib-source.."/> elements myself
• could the generate-module goal add them
• or should the codeserver be invoked with the lib- modules (along with the app- modules) and already re-compiles dependent modules automatically.

I hope this clarifies my problem.

To answer your question, i would like to see the following output:
<module rename-to="app-user">
<inherits name="<package>.LibApi"/> <-- lib-api project module name (already generated) -->
<source path="lib-api"/> <-- lib-api project sources -->
<source path="app-user"/> <-- this app- projects sources -->
<entry-point class="<package>.app-user.AppUser"/>
</module>

for the module.gwt.xml from the app-user project:
<module>
<source path="app-user" />
<entry-point class="<package>.app-user.AppUser" />
</module>

and the module.gwt.xml from the lib-api project:
<module>
<source path="lib-api" />
</module>

[tbroyer]

The source path for the lib is already declared in the lib module, so there's no reason to declare it in the app module.
Could you run Maven with the -X flag and copy paste here the command line used to launch the codeserver that you'll find in the logs? Also, which version of GWT and of the plugin are you using?
Oh, and how are you declaring your dependencies to the lib modules in your app POM? Do they have <type>gwt-lib</type>?

[auke-]

The lib- projects have packaging gwt-lib and the app- projects have packaging gwt-app and declare the lib- dependency with type gwt-lib.

The codeserver is invoked with the src/main/java paths for all lib- and app- projects (e.g. -src lib-api/src/main/java -src app-user/src/main/java) and only the app- modules as arguments (e.g. <package>.AppUser). The target/classes paths for all the lib- and app- projects are on the classpath.

The -src and classpath variables doesn't seem the problem, but the modules might. One thing i could think of is that the codeserver needs the module names of the lib- projects, but thats just a guess.

I still use 2.7.0, but want to switch to 2.8.0 as soon as its released.

The strange thing is, after removing all redundant source elements, upgrading the gwt-maven-plugin to rc-5 and rebuilding everything I can't reproduce the issue... And i'm unable to reason why it (sometimes) didn't work in the past. Could it have something to do with putting ui.xml files in src/main/java vs. src/main/resources? The codeserver isn't aware of src/main/resources.

[tbroyer]

Files in src/main/resources need to be processed (generally copied –possibly relocated and/or filtered– by resources:resources at the process-resources phase), they'll be loaded from the classpath (they'll end up in target/classes). Putting those files in src/main/java removes the need for that process-resources step each time you modify a file (could be automated by the IDE though; I think Eclipse does that automatically on save), but then you can't use relocation or filtering (at least during dev mode). This is fine in most cases though, very few people use relocation and/or filtering on those files, and many wouldn't mind not having filtering in dev mode. TL;DR: src/main/java is fine, and has a better UX in most cases; src/main/resources requires invoking process-resources to see changes.

Closing as you can no longer reproduce. Don't hesitate to reopen if it happens again.

[auke-]

Thank you for clarifying that!