On Jul 3, 2006, at 4:54 PM, Alan D. Cabrera wrote:
I think it is still a good idea to have them all extend from a
parent pom... there is still stuff that would be good to
centralize, but the parent and the child do not need to exists
within the same tree and do not need to share the same version.
I see no reason for there to be a parent POM. What stuff needs to
be centralized? Can you explain what the phrase "the parent and
the child do not need to exists within the same tree and do not
need to share the same version" means?
There is a bunch of shared config... like maven-one-plugin, ci, jira,
deployment (ssh), plugin repositories, distro mgmgnt. About 80 lines
from the current pom.xml for specs is going to be the same across all
specs modules. Which minus spaces is about 1/3 of the pom.xml. Its
about 1/2 of the pom when the bulk dependencyManagement is removed
(since it won't be needed to resolve all specs in every module).
I recommend creating a top-level spec-config/trunk/pom.xml that
has all of the common pom configuration... then release it a 1.0,
and have each of the spec pom's extend from that. Spec config
will almost never change (unless we have to change project urls or
repos)... but when we do, its easier to manage in a central place.
The whole point of this change is to get *rid* of the root POM.
I thought the point was to allow the life-cycle and version of specs
to be independent from each other.
I think we eventually need a general project-config module that we
can share with all sub-projects. That module would be part of a
build-support project where our independent custom modules and
build configuration lives.
Why?
Because it is easier to manage shared configuration in this manner.
--jason
