Thanks Thomas. That makes sense. Good to get some more knowledge about the plugin (which is fantastic btw. If it didn't exist, I would be in a lot of trouble, so thank you for creating it!).
And yes, I'm definately in the 95% not proficient with Maven. 😁 On Saturday, 5 April 2025 at 3:22:15 am UTC+11 Thomas Broyer wrote: > On Friday, April 4, 2025 at 5:33:04 AM UTC+2 [email protected] > wrote: > > Maybe my situation was different. Google App Engine required an > executable war / jar. Ie: It must run like this "java -jar my-app.war". > The GWT Eclipse Plugin couldn't build this, thus I switched to the GWT > Maven plugin. > > But I admit, the GWT Maven plugin is a little confusing. > > > If you're not proficient with Maven (like 95% of its users), mostly poking > at it until things work (nobody will blame you, documentation is really > lacking), I admit it can certainly be. Maven's design is broken > <https://blog.ltgt.net/maven-is-broken-by-design/> in many ways > <https://blog.ltgt.net/maven-is-broken-by-design-2/> (Maven 4 goes into > the right direction, but it's been years in the making and still not there > yet) but it has much more to offer than how most people (try to) use it. > > > Right now, my top level pom has "<packaging>pom</packaging>". My client > module has "<packaging>gwt-app</packaging>". And my server module has > "<packaging>war</packaging>". Why is the client packaging called > "gwt-app", why not just called it "war" like the server. > > > Because it's not a WAR per se, it's just some ZIP archive that contains > the output of the GWT compilation. The only reason the output file is named > .war rather than .zip is such that it can easily be used as an "overlay" by > a the maven-war-plugin (technically it could be a ZIP, but the > maven-war-plugin requires them to be declared in the plugin configuration, > which means there's no dependency from the server to the client, so Maven > doesn't know that it has to build the client before the server). IIRC, this > also was before "webjars" were widely supported (and a few years before > Spring Boot); and webjars have other issues: you don't want any of the > dependencies from your "client" POM to be resolved when depending on it > from the "server" module, which a war gives you "for free": > https://maven.apache.org/ref/3.9.9/maven-core/artifact-handlers.html > > But as Elias said, the "packaging" in a Maven POM opts in to a build > "lifecycle", and this actually is the only reason for that > <packaging>gwt-app</packaging>: > https://tbroyer.github.io/gwt-maven-plugin/lifecycles.html / > https://maven.apache.org/ref/3.9.9/maven-core/default-bindings.html > In other words, this is just how Maven works. > > > And why does it need to know how the server will be packaged at all, > > > It doesn't (nowhere in the plugin > <https://github.com/search?q=repo%3Atbroyer%2Fgwt-maven-plugin+war+path%3A%2F%5Esrc%5C%2Fmain%5C%2Fjava%5C%2Fnet%5C%2Fltgt%5C%2Fgwt%5C%2Fmaven%5C%2F%2F&type=code> > > will you see it look at the server module and/or how it's packaged). You're > free to use the produced .war archive the way you want. Use the > maven-resources-plugin to extract its content if you prefer, it's not a > real WAR, it's just a ZIP archive with a .war name, due to Maven's way of > resolving things and other limitations. > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/ad4bf9a3-49ce-49c4-a233-0153a8cf8917n%40googlegroups.com.
