Here is a mail outlining the module factory changes we are looking at in JBoss Tools (written by rob): So after connecting with Max at JBossWorld and demonstrating some of the code and APIs that are available to us, we've got a strategy for what our projects should look like, and how this should *not* hurt our long-term strategy of keeping the projects easy to use, configurable in one place, and overall clean and solid for everyone. We *will* be making as many of our projects as possible be "Webtools" projects. The key thing that makes this possible without complicating everything is the new reference resolver API which I'm trying to get into WTP, but which we have a version of right now. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=282269) The interesting thing is the component.xml, which links project types together, has a "dependency" tag, which means you can say the ear should have the war inside it. This is well and good, but the dependency tag has *two* dependency TYPES. The first is "uses", and that's where it would end up something like some.ear/inner.war/all/the/files. However the second type is "consumes" and what consumes does is basically pretend anything inside this second project (or component, which is not limited to projects) would be injected directly into the ear as if it was part of that project. Basically, what this does is just ignore the inner component's name, and what you'd get is something like some.ear/all/the/files. Now, why this is absolutely awesome is that with the API addition that's coming, we can create references based on whatever we want, whenever we want. There have been many many longstanding bugs in WTP from people who want to embed a java project, but do *not* want that java project to be forced to become a WTP project. Using the new add-reference wizard, we have the ability to make *anything* consumable; anything that we want. Plain java projects, anything. I don't have all the code committed yet, but today I played around a *lot* with the possibilities and with a few classes, I managed to add this to an ESB project's component.xml using the standard wizard which will be in WTP: <dependent-module deploy-path="/" handle="module:/org.jboss.ide.eclipse.as.wtp.core.vcf.outputFolder/ESBPro"> <dependency-type>consumes</dependency-type> </dependent-module> The key part to look at is the handle, which I get to resolve. I take that handle and add turn that into a Virtual Component of my own, one which returns *only* the resolved and mapped resources inside the ESBPro project. I could also make one to return an IVirtualComponent based on a plain old java project if we wanted... or a classpath container, or *all* exported classpath containers, or whatever I want. This clearly opens many doors for the user, and it means that this new flexible structure should definitely be our direction. Most of the code is already committed but if you use it today or tomorrow you'll notice it doesn't "finish" by actually publishing the source. That's because I spent a lot of the time working on the infrastructure and still need to make a few utility classes to help with the last part. But the way is made clear and this is pretty solidly awesome. I'm not sure if I'm being linguistically adept enough right now, so if there are any questions feel free to ask.