Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.


  • 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.
  • No labels