The GWT context 💎
GWT is a powerful tool, but sometimes this power might get perceived as complexity.
Long unnecessary explanation here...
For further actions, you may consider blocking this person and/or reporting abuse
Great intro to GWT !
Two small notes :
you talk about sharing code with the server, but being Java you can also just as easily share it with an Android app, and with J2ObjC with an iOS app.
out of curiosity, why are you using
skipModule
andsrc/main/java/me/App.gwt.xml
, vssrc/main/module.gwt.xml
?(I won't start a flamewar about putting the
index.html
andApp.gwt.xml
insidesrc/main/java
orsrc/main/resources
😉 should we add asrc/main/gwt
?)Oh, I missed this comment. As always, thank you very much for reading and proposing improvements! I have updated a bit changing "share between client and server" with "sharing cross-platform code (JVM, Android, web, and ios)". I need to review it a bit.
About using skipModule, I commented about that many years ago. Although I think it is a pretty good idea, in practice (and IMO) it just add more confusion to how GWT works and how to create a GWT project. I still think this is a perfect approach to be enforced in GWT3 plugins, but using it in the super slow and confusing GWT2 world was a bad idea. If I was used it I'll need to explain that GWT works using
App.gwt.xml
, but that if and only if you use the tbroyer maven plugin you can auto-generate it, then I need to explain the gwt-lib type (used to auto-add inherits), that is not the same that gwt-lib package, and that you need to put it in a different folder... etc.About
index.html
andApp.gwt.xml
; yep, this might not be the best suggestion for a beginner. But I really don't like what happens if you put it in the resource folder, it gets duplicated into thetarget/classes
folder, then if you modify it in the resources folder, it might not be updated by your IDE in the target folder, causing a confusing situation for them. So, I just leave it there for this minimal starting guide. But yep, in a library project, I won't do that for sure! Thesrc/main/gwt
, please, leave it for the gradle version 😉There are basically two approaches to learn things:
src/main/module.gwt.xml
and<moduleName>
src/main/module.xml
, choose a package name and configure<moduleName>
from it by appending a simple name, e.g..App
, and put your code in a.client
subpackage; also configure themoduleShortName
which will be used to compute the name of the output JS files), then progressively (not necessarily in the same article) explain what happens under the hood (e.g. "actually, GWT needs a module as input that needs to live in a package; the Maven plugin will rename yoursrc/main/module.gwt.xml
based on the<moduleName>
, and will inject arename-to
attribute with the<moduleShortName>
")You can choose either approach, but IMO you should stick to the one you chose.
It should also be clear whether the target audience are people new to GWT, or people who already used Maven to build GWT apps. For the first group of people, you need to put apart your own feelings about migrating from Mojo's plugin to mine; for the second group you'll likely want to explain how to convert their project, or at least what the differences are between their old approach and the "modern" one (your own term)
But well, this is your article, not mine; and (disclaimer) I haven't re-read it (just skimmed through).
Very nice article! You suggested me to try experimenting using GWT with VS Code (using the MAven pluign): I followed you article and was able to do everything step by step using VS Code instead of IntelliJ. Very nice! I would be intereseted in a second article regarding also the server part. How can I add a server part to this simple sample project explained here? What 'mvn' command should I run to start also server side code? My final goal is to be able to fully create and manage (edit, run, test, debug) a maven gwt project inside VS Code. Are you going to pusblish a new articole on this? Could you answer to my questions and doubts? It would be very nice. Thanks.
Our approach to managing the server-side is quite straightforward and has proven effective for many years. Essentially, we use embedded servers and programmatically run them via a Java main method. You can see an example of this approach here. This method involves running or debugging a plain Java executable, which is highly compatible across different environments.
Although it's possible to compile GWT and integrate it on the server side to make it accessible through the same server, we have moved away from this method. Currently, if you're utilizing Docker, you can set up an httpd or nginx server in just a few lines. Additionally, configuring the GWT perfect cache requires only a few extra lines. This method is more straightforward, offers better performance, and provides the flexibility to update the client side or maintain multiple client-side versions. For an example of a Docker configuration that achieves this, check this docker config.