Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging for gwt-app misses Web application sources and overlays #8

Closed
OliverO2 opened this issue Jun 11, 2013 · 4 comments
Closed
Labels
invalid This doesn't seem right

Comments

@OliverO2
Copy link

Static webapp sources and war overlays (dependencies with <type>war</type> and <scope>runtime</scope>) should be included in a gwt-app package. Packaging should essentially be compatible with the Maven war plugin to honor The Maven Way™.

These capabilities are currently missing in the plugin. In addition, there are no configuration options to include additional files in the archive.

Use case:

  • Include a static HTML host page in the packaged gwt-app.
  • Include Javascript sources packaged as war artifacts from framework dependencies.
@tbroyer
Copy link
Owner

tbroyer commented Jun 11, 2013

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

@tbroyer tbroyer closed this as completed Jun 11, 2013
@OliverO2
Copy link
Author

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
Copy link
Owner

tbroyer commented Jun 13, 2013

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
Copy link
Author

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 ;-).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants