Dependent maven projects not being added to STS's 'Maven Dependencies' folder.

STS 2.6.1

STS project TSWeb is dependent upon TSService, but after adding TSService to TSWeb's POM I find TSService is not listed in TSWeb's 'Maven Dependendencies' (M-D) folder but the project is listed within the POM and is shown in the pom editor's 'Dependency Hierarchy' & 'Effective POM' tabs. Crucially, service classes in the project are not visible to the Web application. TSService's own dependent jars are added to TSWebs M-D folder.
No amount of 'Update maven dependencies' of 'Update project configuration' seems to make the Service folder appear in the M-D folder. All the jars from the Service project are added.

STSWeb is a Spring Template Project, 'Spring MVC Project'. STSService is a hand crafted Spring, Maven project.

If I handcraft the STSWeb project from a 'New Maven Project' skipping the archetype selection. I can add TSService with no problems, I conclude is some attribute of the template project that is the problem?

What is the mechanism that adds other projects to the Maven dependencies folder, or how can I fix the problem?

Sorry for the long post.

I redeployed STS & rebuilt workspace. TSWeb now has a 'Web App libraries' folder containing the dependent maven projects - i.e. it all works okay. Looks like for Dynamic Web Modules, dependent projects reside within a 'Web App libraries' folder, not 'Maven Dependencies' as for other project types.

I encountered further examples of multi dependent maven projects where a project could not resolve type dependencies on another even though the pom relationships were correctly defined (In an STS workspace). The solution (less drastic that above) was to close the projects, delete the .settings & all other eclipse '.' resources from the projet folder. Then delete the closed project from the workspace through STS (but not deleting the underlying files). Finally import the project 'Existing maven Project' back into the workspace. It seems to work every time. I suspect the eclipse .resources are being easily compromsed & rebuilding them with the pom dependencies already established cleans things up.