This is an old site!
must be able to just check-out project(s), have Maven Integration for Eclipse (m2e) fetch dependencies, and Run, go.
must fully support resolve dependencies from workspace projects (if they are materialized and part of the workspace).
must support extending binary packaged web application core modules pulled from a repo with additional code/pages
Eclipse generated and CLI Maven generated build artefacts (target) should be kept in separate directories
No CLI e.g. mvn install or mvn war should ever be needed while working on coding & tests within the IDE
Be very FAST, avoid silly file copying around (e.g. *.class and *.jar) in the workspace
Web server/container/engine must NOT have to be separately installed manually (it's "just another dependency")
Maven-based headlesss builds must work as always, and any solution chosen must ultimately still build a standard WAR for out-of-workspace deployment.
The underlying problem is of course a lack of modularity in the original Servlet specification, with all "web content" of one application expected to be in one directory by Java web containers. Web content includes (a) pages, static content like images, JSP etc. and (b) "servlet context" resources often in WEB-INF, and lastly (c) classical classpath resources of the web application under WEB-INF/classes and WEB-INF/lib (*.JAR files). The first two are typically under src/main/webapp in a Maven layout web project, while classpath resources are from src/main/resources and (compiled from) src/main/java, as in a normal non-web Maven Java project. (The Servlet Specification 3.0 version has addressed some of these concerns.)
Ideally, instead eternally trying to get M2E and WTP to like each other, or hacking something which typically involves copying resources and JAR files around to ultimately all end up in that one "web content" directory where the container even in a development environment expects everything to end up - with varying degrees of developer productivity.
In non-web pure Java module/s, say some back-end code, this is of course addressed by fully Classpath-based modularity and resource loading (if you have understood not to work File-based anymore but get all resources via the Classpath; Spring's Resource interface is a great abstraction here of course, missing in the JDK).
While ServletContext.getResource() "does not use class loaders", I've found that it actually isn't all that complicated to, for a development environment, set-up a purely Classpath-based web container anyway. Many Servlet Engines, including Tomcat unfortunately (as far as I have found), aren't entirely ready (yet?) for such an approach, but Jetty, via it's explicit embedding support, is just perfect for this purpose.
http://mifosforge.jira.com/wiki/display/MIFOS/Workspace+2.0
Please git clone the code from https://github.com/vorburger/EclipseWebDevEnv/tree/servlet30-jetty7/simpleservers/ (contact me if you want me to make a ZIP available).
Focus is on web component modularity only; in a real world application, non-Servlet back-end code from a package such as ch.vorburger.demo.core.services would probably be in a separate module than the front-end ch.vorburger.demo.core.web kind of code; in my blueprint they are together for simplicity, pushing the modularity further, based on what I'm outlining, is obvious.
BTW: Of course, once you have such a set-up, one might as well package up the Jetty server into a ZIP package, so that whoever uses your web application doesn't have to go about installing a container, configuring it, and then dropping your WAR into it. As an option. Unless you're "in the enterprise" - then of course standards compliant packages that fit into containers well entrenched in IT are a must. (The most successful Java applications such as e.g. Hudson & Atlassian's stuff, come packaged like this of course.)