This proposal is heavily inspired by the changes that are made to many linux applications within the last years. Apache, crontab, X11, php...
My debian machine has 45 "*.d" directories within /etc...

Problems with huge poms 

The pom.xml files I use sometimes become really huge.
Escpecially if developer informations and other "static" data is added the poms start growing really fast.

The informations described in the pom cover many different scopes and are changed with a different rate.

There are several shortcomings when only one file is used to store all those informations.

• big (maybe unreadable) file 
• many revisions due to many changes; results into
  • hard to track changes (ever tried to find the revision a dependency has changed for a fast-changing pom?)
• more (unnecessary) conflicts/merges in a multi developer setup

Proposal: "pom.d"

Of course it is very easy for small projects to just create a small pom.xml. So I suggest to keep this possibility. But optionally it should be possible to create a directory called "pom.d"

All files within this directory are virtually merged to one pom.xml file. So it is possible to keep several files for different scopes. Best practices could be to create a file for dependencies ("dependencies.xml"), one for build configurations, another for the developers section. The file names should/could reflect the name of the xml tag they contain/represent.

Benefits

•  Changes can be tracked down much faster
  • searching for dependency changes only affects revisions of "dependencies.xml"
• Lesser conflicts/merges necessary
• shorter files --> easier to navigate and locate informations
• template/shared files may be copied/linked into the directory
  • some other proposals ask for thinks that could be solved with this option very easily
    • http://docs.codehaus.org/display/MAVEN/Templated+POM+Sections
    • http://docs.codehaus.org/display/MAVEN/Terse+POM+Syntax+-+Design+Discussion
    • ...
  • this could be done using SVN copy / external definitions. But maybe there could also be added some kind of special references later.
  • Adding hibernate/spring/myComplexDependency could be a one liner.

Backward compatibility

I suggest to keep the current behaviour and add the new pom.d directoy only as option to offer an easy way to migrate maven 2.0.x projects. Creating a new plugin that converts a pom.xml into a pom.d directory with several files within should be a task of only a few minutes.

Autogenerating a pom.xml for backward compatibility is an easy task too.

Necessary changes

Only the parsing code of the pom.xml must be changed.

One problem is, that there exist several 3rd party parsers (IDE integration etc.). But they should be able to implement the changes very fast.