I am still very disappointed to see that 5.0.1 did not fix any of the major web app problems. Specifically:
1) The wrong web.xml is copied over to the exploded dir sometimes: if ModuleX depends on ModuleY, sometimes ModuleY's web.xml is copied. The only way to fix this is to open up the exploded dir, delete web.xml, and rebuild. This was claimed to be fixed before 5.0 was released.
2) With multiple web app modules structure with complex dependencies (though no circular dependencies) such as X->Y, Z->Y, and W->Y, without changing a single file the copy procedure can happen unnecessarily. This was a bug that I was told was resolved in 5.0.1. To be fair: it seems to be somewhat fixed (at least with my test case), but is still problematic.
3) This is a bug I haven't reported, but it is still important: when ModuleX depends on ModuleY and ModuleZ, collisions amongst the JSPs are not resolved using the order defined in ModuleX's Order/Export tab. Rather, they appear to be either random or alphabetical (ie: the order listed in the project).
Overall, I've found the quality around this feature is very bad. I took time out to restructure our project files to use this feature with the assumption that everything was fixed in 5.0.1. However, after a couple days of playing with it and more than half the engineers running in to these various problems, I can no longer depend on this feature.
We have moved to a custom Jetty launcher that looks directly in our sources. I hope that at some point JetBrains can do a review of the web module deployment code -- it needs it very much.
PS: I don't mean to be a drag -- IDEA is still by far the only editor I will use... it is just too good. But I do feel that there are still some nasty bugs that crept through in this release:
- web module support (see above)
- the VM param "-cp" is not honored and breaks things when you run or debug applications. This has been broken in EVERY single release -- PLEASE write an automated test for this. Because this doesn't work, we can't even launch Resin the way we used to, which provides fewer alternatives in light of the broken web module support.
- when specifying an alternative JRE, the same classes are not put in the classpath (namely dependent module's outputs).