I've read that it's supposedly a good idea to split an aggregator project (the one with all the module declarations) from the parent/dependency project (the one with all the shared or common dependencies). So that the parent project is not the one you use to do a full build.
Why is that?
Aggregator projects generally package up all dependent projects somehow (e.g. as a J2EE EAR or WAR archive, or as a distribution ZIP), which requires all dependent projects to be built first.
However, a parent POM must be built before it's children projects.
If the parent project is also the aggregator, then you have a circular dependency:
Aggregator depends on children dependencies, which depend on the Aggregator parent.
In our build system we solve this by having a parent POM file that is also the reactorizes it's children. One of the children is an aggregator, which depends on the other children and creates the distribution artifact. Maven dependency resolution allows us to build the top-level pom, which reactorizes all children in the correct order, with the aggregator project last.
In a large environment you may want to have parents that define common behaviour for classes of projects (e.g. a servlet parent, a portlet parent, a war parent etc). Because there is no multiple inheritance in Maven, you either have to have a gigantic parent POM with all this content in and some complicated profile conventions, or several parents, one for each type of project.
Similar projects are not necessarily built together (in fact usually not). To build your projects for a single release you therefore want an aggregator that defines the relevant modules to be built.
There is a section of the Maven book that describes the distinction between aggregation and inheritance. This may help your understanding.