First, one idea about the original question. You might be able to get away with adding src/main/resources as a source folder in the Eclipse project if it isn't already. It's been a while since I've used Eclipse; I don't know if that would be enough to make the GEP happy.
If calling src/main/resources a source folder seems dirty to you (as it does to me), I think a convention of having a src/main/gwt would work nicely. It could be configured in both maven and Eclipse as a source folder. Then GWT-specific .css, .ui.xml, .gwt.xml, etc. files wouldn't pollute src/main/java. > 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. Excellent point. I would really like to see this as well. I don't know much about maven internals, other than the fact that even the most basic operations are implemented as plugins. I assume that it would be possible to add new packaging types using a plugin. > 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). Would it be so bad to have the source for shared code to be deployed as "resources" on the server? I don't imagine they would get in the way, and wouldn't do any harm... as long as they're not some place where the webapp container could serve them... > 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. I think "simple webapps" could still be done using the traditional war packaging. Since everything is in one place, you don't need to worry about packaging the sources. Getting back to the original post, the CSS in that case is definitely a source rather than a resource. Again, it can be in some directory other than src/main/java that is configured as a source folder. > 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) Maven is most definitely a tool aimed at reliable, reproducible builds. To that end, it actually does somewhat of a disservice to developers in cases like this. That's not going to stop a lot of projects from adopting maven, however. Beyond the -noserver option, I think using a tool made for developers, specifically an IDE that understands maven, can help overcome this. I don't think that maven should be configured to reach across the boundaries of modules (as suggested by some on stackoverflow), but there's no reason why an IDE can't... and I bet that most do. If the IDE understands GWT applications and can launch them directly, I bet they do (or at least could) set them up nicely to allow quick change/test cycles. > 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 may not understand what you mean here, but PMD and findbugs operate on the bytecode, so they don't need the source. Checkstyle operates on the source, and I'd be surprised if it reaches across modules when run from the maven plugin. I'm not sure about cobertura (might need the source, or might just use debug info in the JAR). -Brian -- 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.
