Web fragment support

[tbroyer]

Web fragment support

[foal]

Ok. As workaround I use the following configuration for my project. The configuration for maven-jar-plugin is necessary because the compilation result includes the /gwt and /get-units foldes that are relative big

<packaging>gwt-lib</packaging>

...

 <build>
        <plugins>
            <plugin>
                <groupId>net.ltgt.gwt.maven</groupId>
                <artifactId>gwt-maven-plugin</artifactId>
                <version>1.0-rc-3</version>
                <extensions>true</extensions>
                <configuration>
                    <moduleName>org.jresearch.logbackui.gwt.fragment.module</moduleName>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <webappDirectory>${project.build.directory}/classes/META-INF/resources</webappDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <excludes>
                        <exclude>**/META-INF/gwt*/*</exclude>
                    </excludes>
                </configuration>
            </plugin>
        </plugins>
    </build>

[tbroyer]

Your workaround would package all your sources and compiled Java classes too in the JAR, so I'd have rather compiled to some directory separate from ${project.build.outputDirectory} (equivalent to the ${project.build.directory}/classes you used) and configured that directory as the classesDirectory for the maven-jar-plugin.

<plugin>
    <groupId>net.ltgt.gwt.maven</groupId>
    <artifactId>gwt-maven-plugin</artifactId>
    <version>1.0-rc-3</version>
    <extensions>true</extensions>
    <configuration>
        <moduleName>org.jresearch.logbackui.gwt.fragment.module</moduleName>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
            </goals>
            <configuration>
                <webappDirectory>${project.build.directory}/${project.build.finalName}/META-INF/resources</webappDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <classesDirectory>${project.build.directory}/${project.build.finalName}</classesDirectory>
    </configuration>
</plugin>

You should be able to move the gwt-unitCache dir using:

<systemProperties>
  <gwt.persistentunitcachedir>${project.build.directory}/gwt/unitCache/</gwt.persistentunitcachedir>
</systemProperties>

No idea where the gwt folder is coming from though…

An alternative is to use a distinct Maven module that would depend on the gwt-app module and use dependency:unpack to "repackage" it as web fragment in a JAR.
That actually feels much cleaner.

Anyway, that's an interesting proposal, and maybe the gwt-app packaging should enable generating a JAR instead of, or in addition to, the WAR, with just a boolean property. I don't think this should be the default though (nor that it warrants a new packaging type). JsInterop will make it easier to create JS libs though, and it might make sense to create a gwt-jslib packaging type then, but I'd rather wait for GWT 3.0, as building JS libs from GWT still isn't a common use case with GWT 2.x and JsInterop isn't there yet (soon, but not yet).

[tbroyer]

I think using an additional module to turn the gwt-app into a web-fragment jar is the best solution; otherwise Maven is likely to cause issues with dependencies being transitive (and as a result including client-side dependencies into the webapp's WEB-INF/lib alongside the web-fragment JAR)