Solved: truns out this bug was merely a symptom of a larger problem. I'll explain what was happening here first.

I've been using the Servers View of eclipse to publish to and manage the Tomcat v5.5 server (provided in the Exadel installation). When I would remove a web project from the server in the Server View, it would not clean it from the webapps directory (\eclipse\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps). So, even though I was updating the project's .classpath and removing/adding/publishing/restarting, what have you, the original configuration of the web project was persisting in the webapps folder. Massive Headache!

The root cause was an eclipse memory leak in the permanent generation memory (explained under Running Eclipse in the file \eclpise\readme\readme_eclipse.html). Adding the line -vmargs -XX:MaxPermSize=128M to the Target of the eclipse.exe has fixed both issues.

Moral of the story: Bugs often have babies.

Oh, P.S.

To get Exadel to load the dependencies delcared in you pom.xml to Tomcat, when adding the dynamic web project capabilities to your project you need to modify the default value for the Web Root* attribute to point to the target directory, which maven creates when you package your project (mvn package).

For example, when I added JSF Capabilities to my JSF-Test project through Exadel, on the Project Folders page under Web Root*, I pointed it to .../JSF-Test/target/JSF-Test rather than the default, .../src/main/webapp/. Tomcat will then load the contents of that folder (which contains the lib directory that maven generates when you package your project) rather than the webapp directory (which doesn't have a lib directory).

Well, this solution does work but with one problem. If anyone else has tried this solution, you'd have noticed that you need to do a mvn package for every change you make to the source, your view pages, or any of the resources. This is because, since you've pointed the Web Root to the target directory, tomcat will automatically publish what is in there and until you mvn package, that wont reflect your changes.

Since the dependencies declared in the pom.xml are the only thing at issue here, I tried setting the Web Root to the actual web.xml location and just changed the lib location setting to the lib folder under the target directory. That way I would only need to mvn package as I modified the pom.xml. But, it turns out that Exadel is ignoring the lib location setting and instead defaulting to the Web Root setting and creating an empty lib directory there.

You know, this would be just a whole lot easier if Exadel (4.0.3) knew what a pom.xml was in the first place :(.

I'll look into those solutions, thanks.

I've done some more research and this appears actually be an eclipse Web Tools Platform (WTP) issue. I'm using WTP 1.1 and I guess it has a bug with integrating maven's external dependencies into Tomcat under my Servers project. WTP 2.0 just released though and addresses this issue and comes included in eclipse 3.3, but Exadel doesn't support that version yet I don't think.

This makes sense of the issue I mentioned of Exadel ignoring the lib locaiton setting. This was happening as I would add JSF Capabilities to my project through Exadel. By checking the .exadelproject file, it turns out that Exadel was mapping the correct lib folder (under the target directory). I'm guessing it was Exadel's integration with WTP that was creating the empty lib folder at the location of my Web Root location setting and it was WTP that was failing to bringing the lib folder I had specified over to Tomcat. But this may need to be looked into further.