Sounds like a simple fix that would allow us to be friendlier with other build 
systems, like Maven for example.

We flag it as an error because the Web App launch configurations will not work correctly if the output folder is 
not war/WEB-INF/classes.  If you don't use those configurations then it will work for you.

The issue is more about whether or not the war directory should be treated as an input and an output or 
simply an output.  If the latter, then we could create staging directories from which to execute and that would 
guarantee that the war folder remains clean.  It would also cleanly address the dependent projects problem as 
well.  We had long debates internally and settled for the current approach for the first release.

Bumping to critical to make sure this gets addressed within the next point release. 
This is causing a hard time for developer who are using maven build systems. See 
groups thread link for more details:

http://groups.google.com/group/Google-Web-
Toolkit/browse_thread/thread/791832a0e177e87e

Summit the scope of this bug is larger than what can be addressed in the upcoming point release.  Is there a 
particular aspect would you suggest we address in the point release?

Hi,
After some discussion with Sumit, we realised that the war folder issue is just one
of the issues of the plugin. I think the ideal solution for this would be to be able
to configure input and output locations for the hosted mode (Sumit has thought about
this and he'll be able to explain it better than I do).

There are other issues though and I think that they should be easier to address. For
example, the entry point modules selection dialog doesn't work when the *.gwt.xml
files are not in the same source folder as the source code. Concretely, when
following maven conventions, java source code is located in src/main/java and
resources needed in the classpath are in src/main/resources. Following this logic in
a gwt project, the module declarations have to live in src/main/resources and that
results in the module selection dialog not being able to detect available modules.

Another issue with the plugin (probably related to the module detection) is that
warnings about unavailable classes are not available in the configuration previously
described.

You should try out the tutorial available at my blog (http://blog.salvadordiaz.fr) if
you want to know what I'm talking about.

Hope that helps.

After some even further thought about this issue, it seems like getting GWT to play 
with the Maven build process in a flawlessly simple fashion would require changes 
that go beyond the plugin and start touching at the level of the GWT compiler.

Once the necessary tweaks have been made to a project that does want to use Maven 
with GWT, however, it would definitely help if we loosened up restrictions in the 
plugin. For starters, I think Miguel's suggestion of removing the war folder 
structure as an input source to the compilation process and using a staged directory, 
and perhaps even introducing options to specify the staged directory that should be 
used instead (such as the /projectname/target/war/WEB-INF/classes directory used for 
Maven) would help take steps to easier integration.

 Issue 3755  has been merged into this issue.

 Issue 3928  has been merged into this issue.

 Issue 3877  has been merged into this issue.

(No comment was entered for this change.)

This issue is a problem also if you are developing a gwt application as a Equinox OSGi 
Bundle. In that case you need to put the WEB-INF directory in the root of the project 
and not in war. But if you but the WEB-INF in the root you cannot use anymore the GWT 
Eclipse plug-in!

(No comment was entered for this change.)