Looks good for me.
A slight change to the example is needed.
The bom will have richfaces-parent as its parent, not the project-parent.
richfaces-parent --> bom --> project-parent --> sub-module parents/aggregators
I vote for three projects in hierarchy, there is global parent contains global project settings ( developers, license, repositories ), bom project inherits it and defines runtime dependencies ( so it would be used for 'import' ), and module parent defines build configuration ( plugin management, test-scope dependencies ).
richfaces-parent -> bom -> module-parent.
Project aggregator is the forth involved in build and should stay out of inheritance ( that's only because of Maven algorithm of build order calculations).
If modules inherit the aggregator project, Maven build root project first to make it available for modules ). Therefore, if the root project contains aggregator-style plugins ( reports, deployment, assembly, site ) sub-modules are not available at the first root module build, and build should be repeated twice.
Just want to make sure you are saying each module parent should define its own test scoped dependencies?Especially if you are also talking about plugin management section out of richfaces-parent. That would be a large amount of duplication across each module parent. That is why I was hoping a root-parent could serve that role.As I said my concern is a large amount of duplication of test, and plugin config in each of the module parents.
After discussing with Alex:
We are going to have a root-parent, that will actually make it possible for some module parents like core not be needed.
Richfaces-parent will contain only stable configuration items for the project.
Aggregators are still tricky, and will be inheriting from richfaces-parent (jboss-parent) for version info. We are going to attempt to have aggregators "inherit" from /trunk/pom.xml so that it can contain the correct aggregator plugin needs.
Archetypes/Examples need their own parent ( but can wait for later ) - there is already a jira for it.
Alex and I are going to create a development branch for this, and work from there. Everyone else should be able work as normal in /trunk.