All tests have been done using the solution provided in the http://jira.codehaus.org/browse/MNGECLIPSE-59. This solution works very well, but there're specifics when using it with WebTools. Attached are sample projects that demonstrate the issue (tested under Eclipse 3.1.2). Unpack wtp-samples.zip and import projects in the workspace. Patch from MNGECLIPSE-59 should be applied. Rebuild both projects. Build of "web-main" should fail with an error: "Build path contains duplicate entry: 'web-component' for project web-main" The problem occures b/c of conflict b/w Java classpath (in the Java Build Path > Projects) and Maven2 classpath container. They both contain "web-component" project. If go to Properties > Java Build Path > Projects and remove "web-component" project manually everything will compile fine, but WTP will not include "web-component" in the runtime classpath when running the "web-main" project in the servlet container (e.g. Tomcat). To fix that, you have to include "web-component" in the J2EE Module Dependencies for "web-main" (see Properties > J2EE Module Dependencies). When you try to save J2EE Module Dependencies changes, you get the same "duplicate classpath entry" error. J2EE Module Dependencies use regular Java classpath for a project and thus Maven's container should work just fine (theoretically). The problem occures exactly when WTP tries to save J2EE Module Dependencies and synchronize them with Java classpath. It most probably tries to add a project marked in the "module dependencies" to the list of dependent java projects and fails. One solution here could be to source "J2EE Module Dependencies" from the Maven's configuration for a project. J2EE Module Dependencies are stored within the project in the ".settings/.component" and looks something like the following: <dependent-module deploy-path="/WEB-INF/lib" handle="module:/resource/web-component/web-component"> <dependency-type>uses</dependency-type> </dependent-module> This information is present in the POM with dependency scope other than "provided" and "system". If it's not possible to extend WTP to read module dependencies from Maven's POM this issue can be redirected to WTP itself, as there's nothing illegal with the way Maven2 extends classpath (as specified in MNGECLIPSE-59). It's only the synchronization procedure of WTP configuration that fails in this case.