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, become really huge sometimes.
Escpecially if developer informations and other "static" data is added, the poms start to grow 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.

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.


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.

Maybe it is necessary to change/extend the XML schema for those files. Could anyone provide some informations about this issue?