Using assembly:assembly is a Really Bad Idea. Not only does this goal run in aggregator mode, which can cause other assemblies in the project tree to be skipped. It also means your asembly is built completely outside the normal build lifecycle, and will not be installed or deployed with your project.
Too often in JBoss projects (so far), I've seen the use of this goal paired with the use of <moduleSets>/<binaries>, which means that your assembly can only be built using a tortured command line.
It's very important that assemblies build as part of your normal build lifecycle, so tooling built around Maven for downstream consumption of your projects can be more consistent.
The recommended approach is to confine your assemblies to a child project, which declares dependencies on the other modules in the build that it bundles. Then, use <dependencySets> instead of <moduleSets>/<binaries> to aggregate these binaries. Finally, use an <execution> block in the POM to bind the assembly:single goal to the build lifecycle, normally under the 'package' phase. This is the recommended standard, and it works pretty well for 99% of cases.
I'm working on a new version of the assembly plugin that will allow the sane use of <moduleSets>, and the milestone I've published is available on http://repository.jboss.org/nexus/ in the Thirdparty Releases repository. Its version is '2.2-beta-6-m1-jboss'. Basically, you need to add a flag '<useAllReactorProjects>true</useAllReactorProjects>' to each of your <moduleSet> declarations. At that point, you can safely use an assembly with moduleSets from a child project within a multimodule build, and bind the assembly to the main bulid lifecycle.
In any case, move assemblies into a child project, and use dependency declarations within that child to ensure it runs at the appropriate time during the build to consume binaries from other modules.
I'm happy to assist in refactoring these assemblies if anyone wants to find me. Most times I'm on jboss-dev IRC.