This document describes the rest of the requirements for dependency management that have not yet been implemented for Maven 2.0, especially with regards to transitive dependencies.

Requirements

• filtering out transitive dependencies you don't want
  • done at the POM level, or individual the dependency level? (seems to make sense to do it at the pom if you are already excluding by name)
• only resolve dependencies once
  • eg if maven-artifact is in the top level pom, go through the tree and find all the references to it, decide the version, and then use that version's dependencies, not the others
  • this would probably be done with a SAG using just group/artifact ID with counts on the edges. When a version is chosen all the other versions are removed, and when a count drops to 0 it is removed from the graph. Proceed until all versions are determined.
  • this ensures the pool of dependencies is smaller when trying to determine the version to use, and much more accurate.
• declare minimum, maximum allowed versions of a dependency (both min and max may be optional). Allow holes for known incompatible versions
  • suggest syntax of comma separated list of ranges, eg -1.0, 1.2-1.3, 1.5+ (this excludes 1.1 and 1.4, but 0.9 and 1.6 are fine)
  • single version is considered a "soft requirement" and backwards compatible (more of a recommendation)
  • explicit version would be 1.4-1.4
  • use of - may impeded its use inside version string, maybe a better alternate syntax is
    • (1.0], [1.2,1.3], [1.5) as above, or [1.4] for an explicit version
  • of the set of possible versions, the default would be to use the newest
• local definition always wins
  • would rather not have to redeclare a dep not explicitly used just to force a version
  • should use dependencyManagement for all this information if possible
• resolve ranges to actual versions at release to make builds reproducible
• warn on workable but possibly bad combinations of versions
• pluggable strategies for conflict resolution
  • use-range (as above), use-nearest (ignore ranges, always get closest), fail (if any mismatch found)
  • strategy might be specified on project or dependency?
• describe the versioning strategy to ensure consistency.
  • may later make this pluggable, but not for 2.0
  • <major>.<minor>.<revision>[-<build>] where the build section is optional (and is SNAPSHOT, alpha-1, alpha-2, etc leading up to release, then -0, -1, -2 after release for reconfigured builds) and any '0' build or revision elements can be omitted.