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 and App.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 the target/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! The src/main/gwt, please, leave it for the gradle version 😉
There are basically two approaches to learn things:
bottom-up: explain the concepts of GWT modules, what are the GWT tools and what their inputs are, say what needs to be done, then finally how it can be done with Maven, and in that final step you can say that the module is generated from src/main/module.gwt.xml and <moduleName>
top-down: explain how things are done with Maven and what commands to use when (create a 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 the moduleShortName 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 your src/main/module.gwt.xml based on the <moduleName>, and will inject a rename-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).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
skipModuleandsrc/main/java/me/App.gwt.xml, vssrc/main/module.gwt.xml?(I won't start a flamewar about putting the
index.htmlandApp.gwt.xmlinsidesrc/main/javaorsrc/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.htmlandApp.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/classesfolder, 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.xmland<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.clientsubpackage; also configure themoduleShortNamewhich 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.xmlbased on the<moduleName>, and will inject arename-toattribute 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).