On 4 March 2011 19:53, Brian Reilly <brian.irei...@gmail.com> 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). > > Java code is just one example. Groovy and Scala are not Java, but are > still source code. I would also consider .ui.xml files to be source > code. Leaving aside libraries for the moment, they are not bundled in > the final artifact and are instead compiled into an entirely different > form.
I haven't worked with Groovy/Scala and Maven. Are you saying Groovy/Scala code is supposed to go in src/main/resources? That would indeed be strange. The *.ui.xml files are certainly outliers. It would be nice to have separate directories for specific GWT stuff. Maybe src/main/gwt-resources or simply src/main/gwt. >>> 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). > > True. However, by default, there is an implication that resources will > be copied (possibly with filtering) directly into the target packaging > area during the build. Here's a subset of the maven lifecycle. Note > the description of process-resources (I've included the surrounding > phases for context). > > * generate-sources: generate any source code for inclusion in compilation. > * process-sources: process the source code, for example to filter any values. > * generate-resources: generate resources for inclusion in the package. > * process-resources: copy and process the resources into the > destination directory, ready for packaging. > * compile: compile the source code of the project. > * process-classes: post-process the generated files from compilation, > for example to do bytecode enhancement on Java classes. > > If you have files in your project that: > > * are needed for compilation > * don't fit in any other source directory under src/main (e.g. src/main/java) > * shouldn't be included in the final artifact > > you can either: > > * put them in src/main/resources and configure a resource exclude > * add another source directory under src/main and configure a source include Yep, agreed. > The types of files that Thomas mentioned are in this category. If I > were to be concerned with not polluting src/main/java with these, I > would choose to add another source directory. I'm too lazy to do so but I agree. :-) > Finally, as Thomas pointed out, whether or not the files are included > in the final artifact depends on whether it's an application WAR or a > library JAR. I've been assuming WAR above. For a JAR, I would probably > use the same directory structure for consistency and just change the > includes/excludes to get the files packaged correctly. > > Though I also agree that it's unfortunate that they can't be > configured the same, compiled separately, and linked together for the > final application WAR. > > -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 google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
