I have the feeling the POM will carry too many things. After all, POM is in SCM, so it is versionned, it is source related, it can't provide deployment infos, or development platform context, which can change after the release has been done.
At the first reading of the POM documentation, I see : <reposiroty> : Remote Repository. (I guess the one where the packaged artifact will be deployed) Does it mean that my project sources must know where my remote repository is installed ? What happen if my company change computer names (for example she got bought by another company who already have a maven repository and we want merge them) ? This problem was already an issue in Maven 1 too, and still is on those : issue management, site:deploy target, etc. I have slightly the same conceptual difficulties with some site reports. For me there are different kind of reports. Some I want to execute during Continuous integration (on SNAPSHOT) and some I want to execute on stable releases (versions). Some reports can be attached to both : javadoc, tests, xref, faq, install guide, user guide, pmd, findbugs, checkstyle, ... they apply to ONE configuration. Some reports are NOT version related, they apply to the whole configuration management : last 30 days changelogs, Developper activity, ... If the changelog was : every change log since last version, it would become a configuration report and I would be ok with it, but the fact it will deal with a period of time based on when I run it, breaks this (I should be able to check out a specific VERSION, whenever I want, even years ahead in the future, generate the site and obtain the exact same result than when i did the first time). I have the feeling Maven doesn't clearly separated between a configuration and the whole project lifespan. For me there should be a tool for configuration-based tasks, and a tool for project-based tasks. A versionned POM, that follow the configuration lifecycle, and some other project-settings separated from the POM. I think this second item should be handled by CruiseControl-like tools, and could integrate other tools that track the project evolution like some code review tools with history (e.g. Hammurapi). Or ? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]