Documentation: war config

[tbroyer]

Documentation: war config

[branflake2267]

I've uploaded that archetype. But @tbroyer stuff is awesome, I like his maven plugin better. I haven't converted all my stuff over yet.

[branflake2267]

We should probably take this chat to another location since it's running off track. But I'll share it quickly here. I haven't upgraded this app in a while so there is a possibility it needs some tuning.

https://gist.github.com/branflake2267/cd2d25d7bd723a716fcfbcad52c97a14

[branflake2267]

By the way, I've gotten a step closer to a better moduleName m2e configurator so it can be renamed in Eclipse.

[branflake2267]

Once I get through my archetype updates, testing your plugin in various configs, I'll loop back to update more docs.

[branflake2267]

Adding the pom.xml for reference. https://github.com/branflake2267/Archetypes/blob/master/archetypes/gwt-basic-rpc-appengine/pom.xml

[slugmandrew]

@branflake2267 I tried to build a project from the gwt-basic-rpc-appengine archetype 2.0-SNAPSHOT but it seems it isn't deployed to sonatype... https://oss.sonatype.org/content/repositories/snapshots/com/github/branflake2267/archetypes/gwt-basic-rpc-appengine-archetype/ only shows the 1.0-SNAPSHOT.

I'm trying to modify @tbroyer 's modular-webapp archetype to use app engine so it would be great if I had the 2.0 version of yours which shows how to launch app engine instead of just plain jetty. I'm trying atm but struggling to work out what goes where.

[tbroyer]

@slugmandrew AFAICT, it should be as easy as running cd *-server && mvn appengine:devserver -Denv=dev instead of cd *-server && mvn jetty:run -Denv=dev, and changing the launcherDir in the root POM to point to the *-server/target/*-server-${project.version}. The problem with this approach is that the SDM .nocache.js stub is generated in *-server/target/*-server-*, i.e. in the prod target dir, possibly overwriting your prod compilation when assembling the final WAR. Ideally, you'd want to build to a different target dir when using -Denv=dev but that might make your build complex and brittle; so, well, just remember to mvn clean before you package your app for production. You can also have a look at the MobileWebApp sample in the GWT SDK (or the GWT source repository)

BTW, closing this issue now that the GWT samples use this plugin; plus, I really don't think you should work that way and should rather split your project into modules, like in my archetypes.

[branflake2267]

FYI, I've changed how I use app engine. That means I'm using the old app engine maven plugin in that archetype. Google has built a newer maven plugin that works much better, but the only way to use it's configuration is to use a server runtime in eclipse to debug it. http://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/AppEngine.html - And oh, I see what you mean, the 2.0 is missing and 1.0 has the old config.

[slugmandrew]

@tbroyer I don't think I made that clear enough - I have used your multi-module archetype because I want to have my project split up into modules, based on your advice! And I want to use your plugin instead of the Mojo one. The 2.0 archetype I wanted Brandon to upload uses your plugin instead of the Mojo one, I just want to know how to run App Engine on that instead of Jetty and have SDM link into the page refresh. I've got it working using the bookmarklet in this test project but I'm just hacking my way around really.

@branflake2267 Thanks for that. It's very confusing when you don't know maven well and switching from a single module to multiple ones is a lot to get your head round. I have been using the new appengine plugin for a while but only for deployment (appengine:update). I was still launching it using the <server>com.google.appengine.tools.development.gwt.AppEngineLauncher</server> of the Mojo plugin and thought there might be an equivalent command for Thomas's one.

And yes, Thomas is awesome, as are yourself. You've both helped me many times and I'm really grateful for what you give to the GWT community.

FWIW, this all started as I had help from someone (Chris at Arcbees if you know him) converting my single module app into a multi-module one, but the layout is different from what I'd expected:

• root [parent]
  • client
  • server
  • shared
  • app

I'm having a hangout session with Chris later to discuss the differences in the layouts and the two plugins so maybe then I'll have a better handle on things :-)

[tbroyer]

@slugmandrew Sorry, I wasn't clear enough: the last paragraph wasn't directed to you but to the OP. As I said in the first paragraph though, the next step to make in your test project is to change launcherDir to point to your ${webappDirectory} (beware of evaluation time of the properties though when inherited in modules; maybe you'd have to use businessenergybox-server/target/businessenergybox-server-${project.version} instead), because the AppEngine plugin has no equivalent to the resourcesAsCSV of the Jetty plugin, or the extraResourcePaths from the Tomcat context.

The other differences with the Jetty (and Tomcat) plugins are that:

1. I think you'll have to mvn package -Denv=dev whenever you make a change in your businessenergybox-shared module for your server to see the changes (as the module will be packaged as JAR in WEB-INF/lib, and not loaded from the Maven reactor build; for the Jetty plugin there's a hack using extraClasspath).
2. because launcherDir points to the prod folder, you'll have to mvn clean before you mvn package (or mvn verify) your app, to make sure the WAR will include the .nocache.js from the businessenergybox-client module and not the one generated by SDM.

I'm not familiar with AppEngine though, so I may be wrong, and it could be easier and/or with fewer side-effects.

You can probably also use the -server argument in <devmodeArgs> for gwt:devmode, also setting <warDir> to your businessenergybox-server/target/businessenergybox-server-${project.version} (gwt:devmode uses warDir, gwt:codeserver uses launcherDir):

<devmodeArgs>
  <arg>-server</arg><arg>com.google.appengine.tools.development.gwt.AppEngineLauncher</arg>
</devmodeArgs>

The challenge here would be to have the com.google.appengine.tools.development.gwt.AppEngineLauncher class in the classpath for DevMode without it messing with, say, the GWT Compiler classpath for a production build. Maybe it'd be as easy as using a <profile>.

Wrt the layout suggested by Chris (Christian Goudreau? Of course we know him ;-) ), I suppose the server module is a simple JAR, and the app module simply uses it as a dependency? That's not much different from my archetypes then (and what I'm using in a project at work for several years now): server module from the archetype becomes the app module, and the "new" server module is not much different from any other server-only dependency (e.g. Guice, in my dagger-guice-rf-activities archetype) or the shared module (except that it's only used on server-side so has no constraint on being GWT-compatible like the shared module).
FWIW, we settled on such layout at work such that our server module only depends on other modules containing only/mostly Java interfaces for your services, and the app module is the one bringing the service implementations and wiring everything with Guice; that way, we made sure that the code in the server module could never (even accidentally) depend on an implementation detail.

[branflake2267]

Just my 2 cents, I'd steer clear from using the AppEngineLauncher to start the server. The reason is it's not an effective way to run the Server runtime because it's messy. Google built a much better way to run an app in the server run time, and it uses Eclipse Server Runtimes part of the Eclipse web tools. If you're using IDEA the same effect could be had. I also have seen the complications personally too. But I know folks really like the right click and debug and have the same process all in one. But when it comes down it there are so many gotchas. If you use a server runtime, and this runtime could be run anywhere with GWT as long as the launcherDir points into the war output path. Anyway, to my point, it won't matter how you configure the project if you use a server runtime. That is if you concentrate on using using the IDEs server runtime system, maven doesn't even have to control it. Or even use maven to start the services it won't matter. Then just start the CodeServer entry point and give it two things, the -launcherDir /point/to/server/runtime/war/output/path and module. I think it should be simple if you consider the server first. (Or start DevMode with the usual -war /output/to/war and -noserver)

[slugmandrew]

@tbroyer, @branflake2267, you are both so awesome for spending so much time replying. I will write you both a full response tomorrow, but for now - I think I got it (the auto-recompile) working... does this look right? Particularly the compile-1, compile-2 etc location?

It was as simple as setting <launcherDir>businessenergybox-server/target/businessenergybox-server-${project.version}</launcherDir> and removing <appDir>${webappDirectory}</appDir> from the appengine-maven plugin. See commit here if you're interested: slugmandrew/businessenergybox@61978be

Again, thanks so much and now I'll try and get a similar setup working when I have a hangout with Chris (Christopher Viel actually, but I also know Christian :) ) tomorrow.

[tbroyer]

I believe the appDir line that you needed to removed was because webappDirectory is defined in the root POM, so it evaluates to target/businessenergybox-1.0-SNAPSHOT instead of target/businessenergybox-server-1.0-SNAPSHOT as expected by your launcherDir (exactly what I warned about in my earlier comment). And it happens that target/businessenergybox-server-1.0-SNAPSHOT is the default value that appengine:devserver uses if appDir is not set, which explains why it works when you comment the line out.

So, yes, everything looks good (except you have a bit of tidying to do in your POMs or you'll quickly be weighed down under technical debt)

[slugmandrew]

OK, so I'm along the right lines... I'm understanding this whole process a lot more now, having run gwt:codeserver -X a ton of times and playing with the <launcherDir> and <appDir> properties yesterday.

It's been great for a while (as a maven newbie) to have everything in one place, and the Mojo plugin just go gwt:run and boom - everything is done for you, but obviously that hides what is really going on and is not good in the long run!

I'm supposed to be having a meeting with Christopher now. This is roughly my 5 pom.xml setup as it stands: https://gist.github.com/slugmandrew/1d9acf86be2c7db89031dc60de9df6e2 - a total mess with server and client dependencies in the shared pom, and other bits all over the place (I pass appengine.datastore.Key to client side, etc), because I've been using a single module for years building this app only going by the principle of "anything in shared can be used on either client or server". I am learning though so hopefully with a lot of work over the next couple of weeks I can have some nicely defined boundaries between client and server.

[branflake2267]

I'm cringing I see app engine servlet launcher. :) You'll have to supersource the datastore key. I have done that, but you'll have to ask me offline for that bit. What I'd suggest doing first, perfect the classpath with maven, using maven to launch the app engine server. Then once that is perfect launching the codeserver and push the bits into the server war output directory using the launcherDir. Once you have those two pieces down, you're definitely good to go for debugging. But you probably want to run both launchers in the IDE. What you do here is match the maven launchers using the same classpath. At worst you can copy the classpath into the IDE launcher, annoying at best to do it this way. The IDE should be configuring the same classpath using the plugin tricks. By the way, I'm fixing the code server launcher for this plugin now and a few other things along the way. I've already got the src/main/webb warning fixed. I'm working on the code server launcher now.

[slugmandrew]

Yeah, that was the plan for the datastore key. If you'd like to give me any pointers offline my email is on my github profile page 😀 Or just point me to some code. I've super-sourced one of my own classes before so do I just do the same - mimic the package name and copy every method from the original?

But you probably want to run both launchers in the IDE

I was actually just discussing the different launch options with Christopher, and he had already recommended using IntelliJ to launch both servers. Annoying thing is I'll still have to use that damn bookmarklet but it's not exactly a massive problem I guess. I find it odd I still need the gwt-maven-plugin in my pom for the IntelliJ App Engine launcher to work properly though!

BTW, fixing the code server launcher sounds awesome - let me know when it needs testing (or anything else I can help with) and I'm right there.

[branflake2267]

Since there are AppEngineLauncher notes here. This method of debugging will not be supported for much longer. Google has a new Cloud Eclipse Plugin and IntelliJ IDEA Eclipse Plugin. The goal is to use the CodeServer with -launcherDir or DevMode with and -war to push the bits to the external server runtime.