Packaging for gwt-app misses Web application sources and overlays

[tbroyer]

Packaging for gwt-app misses Web application sources and overlays

[tbroyer]

This is on-purpose: you're supposed to use a gwt-app as an overlay in a war. See also issue #2.

[OliverO2]

Thanks for pointing this out. I've done this and observed the following:

• Overlaying the "naked" gwt-app works, given that resources are re-located into the dependant war module.
• As a side effect, transitive dependencies might have to be explicitly re-defined in the dependant war module.

Example:

• Given a gwt-app which depends on o.a.e:atmosphere-gwt20-client:jar:1.1.0.RC2:compile, which in turn depends on o.a:atmosphere-jquery:war:1.1.0.RC3:runtime, thus overlaying the latter onto the gwt-app.
• As the overlay is ignored by the gwt-maven-plugin's packaging, the originally transitive dependency on atmosphere-jquery:war:1.1.0.RC3:runtime would have to be re-introduced as a direct dependendy in the war module depending on gwt-app.

To me this looks like a deviation from what Maven intends regarding transitive dependency resolution. Is this intentional or did I overlook something here?

[tbroyer]

GWT has a mechanism for publishing static files: its public source (<public path="…"/> in the gwt.xml file, defaulting to a public subfolder).

Ideally a gwt-app artifact shouldn't be different from vanilla JS and there's no standard in Maven for JS (some use WARs as overlays, like Atmosphere, but then you also lose transitive JS dependencies; others use JARs as Servlet 3 fragments, like Bootstrap-Maven; and then there are Maven Tools for JavaScript developers, JSZip and WebJars).
But it also has its own issues, as a gwt-app's jar (gwt-lib) dependencies shouldn't be inherited transitively (and I don't want to force everyone to use <scope>provided</scope> on those); we hit a Maven flaw here in that the POM is used as both input and output: it works well for Java projects, not so well otherwise.
Now maybe I'm just missing something… (should we declare that gwt-lib are not added to the classpath and use a custom javac mojo instead of relying on the maven-compiler-plugin?)

AFAICT, atmosphere-gwt20-client expects that you'll add a <script src="jquery/jquery.atmosphere.js"></script> or similar to your HTML host page, and that page lives in the downstream WAR module, so atmosphere-jquery:war should rather be a dependency of that WAR module; or alternatively it should be embedded into atmosphere-gwt20-client as public source in the GWT module.
Note that the way Atmosphere does it, AFAICT, doesn't work well with non-WAR webapps (standalone servers) as WARs are not put into the classpath (it'd actually depends how you package/run your app; e.g. appassembler-maven-plugin and maven-shade-plugin don't seem to care, Eclipse won't include it though, and I suspect exec-maven-plugin would behave the same). WebJars and JSZip work much better here. Atmosphere's WAR approach also bundles jQuery and could conflict with other jQuery dependencies without Maven being given the ability to handle the condlict (this is as bad as ûberjars); again WebJars and JSZip work much better here (the jquery-atmosphere WebJar simply declares a dependency on the jquery WebJar).

Please come provide feedback on issue #2, but given the above, I start to think that a WAR overlay is the least bad of our choices here.

[OliverO2]

Hmm, I got the impression that the new gwt-maven-plugin with its generation of inherits elements is a step towards a Maven-only configuration. So if we stick to the Maven Way, it should be sufficient to place static files in the usual directories for them to be included in a module. Requiring additional publishing configuration in the GWT module file would be a step backwards to me.

I'm not generally opposing configuration. In fact, I think it's better to have configuration than poorly documented or weakly understood conventions which seem to be at the root of many problems people are experiencing with the Maven ecosystem (me included). However, what I'd like to avoid is having configuration spread all over the place. In this case, I'd prefer to configure the module structure in Maven only. Anyway, as a workaround, I appreciate your hint on the publishing mechanism.

In my recent feedback on issue #2, I've already described a different view on what should comprise a gwt-app artifact, along with views on packaging alternatives. I'm not sure I fully understand all the implications of using gwt-lib modules since I haven't played around with them yet, so I don't feel sufficiently qualified to comment on that at this time.

Regarding the Atmosphere jQuery dependency, I take your point that it should be declared in the module where the HTML host page lives. On possible dependency conflicts with bundled jQuery instances, I agree that nothing good happens after midnight. It seems that Atmosphere is moving towards jQuery-free implementations though, so I might get some relief for free ;-).