For educational purposes I have set up a project layout like so (flat in order to suite eclipse better):
-product
|
|-parent
|-core
|-opt
|-all
<
I'd suggest just keeping the assembly descriptor from "all", move it to parent/ and change parent/pom.xml accordingly, and then create that assembly by doing something like mvn -f parent/pom.xml assembly:assembly
. In other words, yeah, remove the redundant project for "all" since it is just duplicating what "parent" is already doing.
On a side note, "parent" seems like a poor naming choice for that project if it's an aggregate project and not just a parent pom.xml.
[Edit]
Although a much larger project, perhaps a project that is laid out how you are envisioning is the apache camel project. Check it out here: http://camel.apache.org/source.html . There is a parent/ module that handles all of the for everything else, and a separate module for producing the actual build distributions in apache-camel/ (with assembly descriptors in apache-camel/src//main/descriptors). Perhaps that will be more of a help.
Flattened trees are not often used anymore. This was done several years ago to deal with how Eclipse handled projects and the lack of good Maven and Eclipse integration. If you use m2eclipse to import Maven projects into Eclipse, you won't have any problems with a maven-typical nested tree.
As far as what is a good example of how to structure a Maven build? The Maven project source itself. It has all the pieces you desire, including the final assembly that packages up the bundles.
The typical nested structure has a top down hierarchy where the parent is doing the aggregation of the modules below it, and the children are inheriting values from the parent. Although these can and sometimes are separate, this is not the norm.