gulp watch or similar that watch and rebuilds their SASS stylesheets or Babel/Rollup scripts).
Other developers using WildFly probably already have similar needs when dealing with other front-end tools (e.g. AppEngine), then having the server serve the webapp directly from the "exploded war" directory is a must you then configure that directory as the launcherDir and need to make sure you mvn clean before you package your webapp for deployment (or you'll deploy the SDM stub nocache.js instead of the production one). This is how I do it with Jetty and Tomcat in my archetypes, with a specific directory as launcherDir that's overlayed on top of the webapp. I don't know WildFly so can't really comment, but the requirements are: be able to deploy from an "exploded war" and/or (ideally) overlay a directory of web resources on top of the war. The reason we're using gwt:devmode is because I tried a dozen ways to get gwt:codeserver etc to work with the WildFly backend, but I could not get it to work. So, I conceed this is not really "user friendly" documentation, and I'm open to suggestions to improve it but I likely won't ever write any tutorial-like documentation. This is also why I'm providing archetypes (linked from that doc). I understand that's why some people would like to find, but I don't have the resources to write and maintain such documentation. This is documentation for the plugin, not a tutorial for either/both GWT and/or Maven. It indeed uses some advanced Maven terminology the idea being that if you don't know what those things are, I'm expecting that you won't actually need them, and/or you should search for their meaning (what does “reactor” means in the context of Maven? what's an “aggregator goal”? what about the “ process-classes phase“? or the -pl and -am arguments?) It also doesn't explain what GWT's CodeServer does or does not do, as it expects some prior knowledge of GWT's architecture and tooling.
#RC7 TEXT SPAMMER CODE#
Side note: I have a hard time understanding the text in codeserver.html (I'd rather see code example instructions than sentence instructions), but I love the architecture (classpath splitting client/server, packaing types, etc). Notice also how I explicitly discourage the use of gwt:devmode in codeserver.html in favor of gwt:codeserver and discourage its use even more for running webapps (which is what you want to do here, additionally with a custom servlet container launcher) (notice once again how Maven's design is broken, with the test classpath merging all scopes –including provided and runtime– and using them both for compiling and running the test)
Because gwt:compile only uses dependencies with scope compile (or provided or system the same that are used in the compile classpath by the maven-compiler-plugin when compiling the classes with JavaC), dependencies with scope runtime will only be added to the classpath for DevMode and actually also present in the test classpath, when compiling your src/test/java and running your test (so, yes, adding a might be a good idea, but as I said, GWT is moving away from the embedded server / all-in-one devmode with-mixed-client-and-server-classpaths, so I'd rather live with that wart in the test classpath than add support for something we don't want people to actually use). The production (non-SDM) build should not have it in any classpath, but it currently does have it. In rc6 and rc7, we had to add it to the gwt-app normal dependencies, which is a hack because technically the client doesn't need it:
The EmbeddedWildFlyLauncher class is in the errai-cdi-jboss jar. DevMode startServer] superDevMode] ] ] generateJsInteropExports] incremental] failOnError] module at .ArgProcessorBase.processArgs(ArgProcessorBase.java:30) at $AppClassLoader.loadClass(Launcher.java:331) Ignoring :optashift-employee-rostering-shared:jar:0.1.0-SNAPSHOT neither a gwt-lib or jar:sources Did you forget to use gwt-lib in the dependency declaration? gwt-maven-plugin:1.0-rc-8:devmode (default-cli) optashift-employee-rostering.