Should gwt-app generate jszip artifacts?

[tbroyer]

…or should there be a gwt:unpack mojo?

I'd like it if gwt-apps could have the generated files at the root of the package and use a mapping to put them back into a subfolder in the war module, similar to jszip:unpack. I'm not sure there's a real added value though; i.e. is it worth the trouble for users of the plugin?

JSZip: http://jszip.org/

[tbroyer]

@cromwellian Do you have an opinion one way or the other?
(BTW, see also DevModeDesignDoc)

[branflake2267]

What comes to mind first is the gae maven plugin has a gae:unpack and sticking this in the eclipse lifecycle is a pain. the other gwt plugin must do some copying which is nice for the testing web mode from the folder with mobile builds. I'm fine either way as long as there some directions one options :)

Good job. :)

[jnehlmeier]

Not sure if its the right place here, but it would be great to have a gwt-app.zip file after a build that contains GWT compiler output (including additional web resources from modules 'public' folder).

The reason is, that we don't serve static content from our app servers directly but use our load balancers for this task instead. So it would really be nice if we could opt-in having gwt-app.zip (compiled client/shared code + web resources) and gwt-app.war (shared/server code + GWT compilation output that may need to be on the server as well, e.g. GWT-RPC *.rpc files, symbols map for stack trace deobfuscation, etc.) without a lot of maven configuration.

[tbroyer]

@jnehlmeier If you follow The Maven Way™, gwt-app will only contain client code, so the produced artifact (gwt-app.war for now, gwt-app.zip if we go the JSZip way) will only contain the output from the GWT compiler (and only the output from the GWT compiler). You'll then use that as a dependency in your webapp (with war packaging), as an overlay for now, or using jszip:unpack if we go the JSZip way.

An alternative is to rather go the webjars.org way of doing it, by producing a gwt-app.jar where the GWT compiler output is in META-INF/resources so it Just Works™ with Servlet 3 containers; it'd break your scenario though (or slightly complicate it)

[jnehlmeier]

@tbroyer Ah I see, but then I would definitely go the JSZip way or are there any major drawbacks?

GWT apps are not war files per definition. Standalone apps are probably not deployed to servlet containers and don't need to be a war and in a Maven multi module setup the client module don't have to be a war either. Server code could also be written in different languages, so I am not sure if a war file is the best solution. To me it looks like that a JSZip way is a bit more flexible.

Only GWT apps created with GPE could maybe suffer from JSZip as they have client/shared/server code in a single project and a war is what you expect when switching to Maven and building the project. In that case we should maybe just encourage users that want to switch to Maven to split their single project into a multi module project as its IMHO best practice?

Would it be possible to add some filtering to a jszip:unpack? That would support our scenario where we only want to unpack specific GWT compilation artifacts (GWT-RPC *.rpc, etc.) into our webapp/war module.

[tbroyer]

Given the discussion on issue #8, I start to think that a WAR overlay is the least bad of our alternatives, given Maven's state of affair. I'm leaving this issue open to gather more feedback though.

[OliverO2]

@tbroyer I tend to agree with your view on the war overlay solution as the least bad, given the alternatives considered so far:

• The webjars.org way of producing a jar which is structured like a war seems misleading to me. If it looks, walks and quacks like a war ;-), then it should really be a war.
• While the jszip packaging might make it easier to incorporate a gwt-app into a standalone distribution, it does so at the expense of complicating servlet distribution by
  • introducing additional moving parts (jszip plugin, need to unpack) in an already complex setup,
  • deviating from the better known (and hopefully better understood) way of war overlays.

In order to reduce possible failure modes and improve usability (by building on what's already known), I would prefer to stick with war overlays for now.

By the way, I'd say a GWT app should not necessarily be limited to GWT compiler output. Host pages and CSS resources, which belong to the respective GWT app only, should really be packaged as part of that GWT app to reduce coupling between modules. (It's a different scenario of course, if a host page has other responsibilities, such as hosting multiple apps). My personal view is that semantic coupling, not the implementation technology, should be the primary factor of determining what goes into a package.

Anyway, my impression is that if I'd like to have it that way, I could still get it by adding the following configuration to the GWT client module's <build> section:

           <plugin>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                    <packagingExcludes>WEB-INF/lib/**</packagingExcludes>
                </configuration>
                <executions>
                    <execution>
                        <id>package-gwt-app</id>
                        <phase>package</phase>
                        <goals>
                            <goal>war</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

As regards development mode, I currently use a GWT run configuration in IntelliJ IDEA (on the client module only). The gwt-maven-plugin allows me to compile for, package for, and run production and development mode clients simultaneously without switching configurations or requiring mvn clean. I don't know whether the same would apply to Eclipse, though.

On a last note, now that the new gwt-maven-plugin controls the maven lifecycle, is there any reason to stick with binding the gwt:compile goal to the prepare-package phase? I'd expect it to bind to the compile phase right after maven-compiler-plugin:compile, though I have not tried it and I might have overlooked some side effect.

[tbroyer]

Let's think about modules (not in the GWT sense) or projects. Currently, the gwt-app is a way to generate and package JS (and related resources) to be used by something else. The gwt-app can impose constraints on how it should be used: the HTML host page has to include such and such elements with the given IDs, it should load a script, etc. This is similar to how many JS scripts work (e.g. you have to load jQuery first, or include some JS code with a specific "user key", or include some element with specific attributes/class names/ID).

The problem I have with including anything else in the archive (such as some src/main/webapp) is that this is opening the door to other requests like compiling several GWT modules in the same gwt-app thus more or less recreating the war packaging as we know it today (not the way I do it though) with the CodeHaus gwt-maven-plugin.

If you want something "standalone", then use GWT's own way of embedding static resources to be copied as-is: the <public> path.

To answer a couple of your other points (if you have further comments, please contact me by mail, or possibly open issues; let's not hijack this issue):

• webjars takes advantage of Servlet 3; it's not a hack.
• I think you can use the maven-resource-plugin's copy-resources goal to copy src/main/webapp.
• gwt:compile is at prepare-package because you don't need to gwt:compile for running tests. Actually, I think my first iteration did it in the package phase (taking advantage of the ability for the GWT compiler to directly output to a zipped archive. I did it that way (prepare-package) to allow for customizations before packaging (such as copying src/main/webapp ;-) ), and being able to use gwt:compile in a war (simply switching your gwt-maven-plugin from CodeHaus without the need to move files around, and/or as a migration step towards using gwt-app and gwt-lib).

[tbroyer]

jszip hasn't been updated in 2 years; closing.