On 4 March 2011 12:02, Thomas Broyer <[email protected]> wrote: > There's a deeper question there: are UiBinder ui.xml, LocalizableResources > properties, ClientBundle css, images, etc. "resources" or "sources"?
>From Maven's point of view: yes, they are resources, not sources. Sources contain source code (i.e. Java code). > 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". Resources are available to all Maven plugins and tools. Just like, e.g., a Hibernate configuration file. So the fact that a resource is given to the GWT compiler doesn't make it a source (from Maven's point of view). > 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". True but a rather unfortunate consequence of not being able to create real GWT libraries. A "real" GWT library would not need to be recompiled when included in the WAR project. A "real" GWT library would only have resources and JavaScript (assuming no shared or server Java code). > 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). That's an interesting idea. I would still like to be able to actually GWT compile my libraries, though. That would seriously cut down on compile time of the whole app. The GWT compiler would only have to (re)link all the libraries together (I'm guessing) to create the end result. > 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. Yes, I agree. > 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 We create separate widgets that can run independently (in their project). That way you don't need to run the whole app to work on parts. Once such a widget is "done" you include it somewhere else and it cannot be changed anymore (at least not directly in the including project). This alleviates the problem to a large extent. > I tend to think this is on-purpose with Maven: favoring unit-tested modules > rather than "integration-tested", manually tested, applications. Yep. > 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 them? (why is it compiling sources that don't > come from the project.build.sourceDirectory, isn't it the actual bug?) I'm not entirely clear what you mean here. -- 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.
