There's a deeper question there: are UiBinder ui.xml, LocalizableResources properties, ClientBundle css, images, etc. "resources" or "sources"? Because these are all about client-side code, which is meant to be given to the GWT Compiler, I tend to think of them as "sources" more than "resources". In the context of a "GWT library" though, you don't give them directly to the GWT Compiler and you'd want them in the packaged JAR so they'd rather be "resources"; but even Java files play both roles here: compiled by javac (and packaged as *.class files in the JAR) and packaged as *.java files, i.e. seen as "resources". This gets even blurier when your "GWT library" is made of "shared code".
All of these are why I do think that GWT projects in Maven should have a specific type/packaging (or actually several specific types: one for "GWT libraries", that are only packaged as JARs, and one for "GWT apps", that go through the compiler to generate javascript files, that you'd then use in a packaging=war module). See http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-multimodule-archetype.html for an example of what I mean, just using "shockwave" libraries (swc) and "shockwave" applications (swf), later used by a webapp. But there are two kinds of "libraries": client-only code (gwt-google-apis or GIN for instance) and "shared code", where you don't want to have your source code deployed to your server as "resources" in the JAR (so you'd need two JARs). The main "complication" is if you want to still support "simple webapps" where everything (client, shared and server code) is in one module; but I think that if you use Maven, you should have separate modules for client and server code. The drawbacks of all these are: - running DevMode: it'd be hard (or very convoluted) to run DevMode with its embedded server when your code is split in several apps, while still supporting "hot refreshes". But this is actually a global issue with Maven, that you also have when coding a multi-module webapp, see http://stackoverflow.com/q/3636493 I tend to think this is on-purpose with Maven: favoring unit-tested modules rather than "integration-tested", manually tested, applications. We've opted for -noserver and a separate Jetty server (using WTP, but it would work with mvn jetty:run) - some plugins (cobertura, checkstyle, pmd, findbugs; maybe not all of them, but at least some, and I can't remember those) are apparently looking at any class that has its java counter-part in the classpath; or is it the maven-compiler-plugin compiles<http://code.google.com/p/google-web-toolkit/issues/detail?id=3439> them <http://code.google.com/p/google-web-toolkit/issues/detail?id=3851>? (why is it compiling sources that don't come from the project.build.sourceDirectory, isn't it the actual bug?) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
