RichFaces project-parent needed

[jbalunas]

So Nick and I were discussing updates to the richfaces-parent.  I would like to get the dependencyManagement section out of it.  These are too volatile to be in richfaces-parent.

My thought was to have them in the the bom, but as actual defined dependencies.  Since "import" scope only imports dependencyManagement section 3rd party applications, and examples would not inherit these.  Also since all of our projects have bom as it's parent - they would inherit these settings.

This approach has its own problem though - mainly that nearly every pom.xml in the project needs to be updated.  This is because now the bom would be defining the complete test dependencies, and having duplicates in the other pom.xml files breaks the build.

I don't think we should use that approach.  Instead, I am thinking of creating a /trunk/parent/pom.xml since /trunk is effectively a large module.  This would define any volatile test/build specific items, and configuration that really does not belong in the stable richfaces-parent.

In the image below "-->" is  parent inheritance, and "==>" is import

richfaces-parent --> project-parent --> richfaces-bom
                                    --> sub-module aggregators

richfaces-bom --> sub-module parents

richfaces-bom ==> examples, 3rd party applications

I know this is another change ( although fairly minor ), but will hopefully limit the number of richfaces-parent releases in the future.

An alternative to this is that each sub-module parent defines their own test dependencies, but that means a lot of duplicates entried and places to update is test lib versions are changes.

Thoughts?

[nbelaevski]

Jay,

Looks good for me.

[jbalunas]

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

[alexsmirnov]

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.

[jbalunas]

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.

[jbalunas]

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.