Phillippe, I'm in the same situation as you, just multiplied a few times, since I have multiple modules that each have the same copy of my define.css file in them (since you can't use CssResources as a src ...), so I have to drop a whole directory structure into my war. I think - and I haven't tried this yet - but I think that if we moved the define.css to a public directory as defined in the *.gwt.xml file, then it would copy over correctly, and the relative paths would stay correct.
John On Mar 4, 9:14 am, Brian Reilly <[email protected]> wrote: > 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-mul...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.
