Hi Alan, 2009/9/30 Alan D. Cabrera <[email protected]>
> For those of us who are not familiar w/ the complex POM parent hierarchy, > can you explain the advantages that the various parent POMs bring? > Sure, I can try. And again this isn't set in stone or anything. The main reason I went for this structure is that I noticed that the Geronimo project was using it and the Blueprint component was depending on a Geronimo parent pom. So I used that as the starting point. The following poms are in play: /pom.xml This isn't really a 'parent' pom but rather a root pom that includes all the submodules, including the submodule that defines the parent poms. This one is nice and short and allows a full build from the top level directory. /parent/pom.xml Top level parent pom (it's parent is the apache parent pom). It defines general things about the project such as the mailing lists, SVN locations, various URLs and so on. It currently just includes the default-parent module but it might be the right level in the future to include other global things such as an Aries Maven plugin if we ever need one. /parent/default-parent/pom.xml This is a pom that generally concerns around compilation, resource processing etc. It contains shared settings for that. It includes just the java5-parent module, but I can imagine that we might need specific settings for other runtimes in the future. /parent/default-parent/java5-parent/pom.xml This pom contains specific settings that apply to Java 5. This is the pom that actual components should declare as their parent pom. The Blueprint component does this at the moment. If there are going to be components that depend on other Java versions, there will be a need to create a sibling parent pom to this one. Hope this explains things a bit. Best regards, David
