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/888c3099-5843-4c68-b73d-4f2c94ed8d8cn%40googlegroups.com.
