Skip to end of metadata
Go to start of metadata

Design Considerations: Refactoring Artifact Handling for Maven 2.1

Version Ranges

Need more information here about specific design problems with version ranges.

Artifact Identity

  1. Platform-specific Artifacts
  2. Encoding Build Options into Artifact Identity
  3. Alternative Versioning Schemes
  4. Accommodating Integrator Builds

Conflict Resolution

Currently, there is only one implementation of conflict resolution in Maven. In certain cases, users may wish to use alternative methods to resolve these conflicts, maybe even opting to fail the build when a conflict is detected.

These different resolution techniques may not be mapped 1:1 with a given POM. Instead, it may make more sense to allow the user to configure his own preferred strategy, in order to make his role in the development effort simpler. One such example might be QA testers, which may opt to verify that all dependencies are convergent before proceeding with what may be an irreproducible build.

Artifact Resolution

  1. Disabling Transitivity
  2. Refactoring Dependency Exclusions
  3. Refactoring Scopes
  4. Refactoring DependencyManagement Behavior

Specification Dependencies and Provides Notation

It's possible for a given API to have multiple implementations. For example, the JavaMail API has the reference implementation provided by Sun, along with multiple open source versions. In many cases, POM authors will want to specify that a project depends on JavaMail, but won't necessarily want to dictate which implementation of the API is used. Moving to specification dependencies will solve this problem. The specification POM will serve as a pointer for a set of libraries which implement the API. The specification dependency would then be resolved in a number of ways, possibly with user preferences factored in via settings.xml.

Provides notation would be related to specification dependencies, but on the opposite side of the artifact relationship. For instance, Sun's JavaMail implementation would specify that it provides an implementation of the JavaMail API, as would the javamail library built by Geronimo. It would act as a reverse mapping of which API(s) are provided by a given artifact. This provides specification might need to be plural, to allow a single artifact to implement multiple APIs, thereby satisfying multiple specification dependencies from a single build.

Artifact API Improvements

  1. Providing access to POM given an Artifact instance

Other Goals to Integrate into this Document

  • Rollback/Control over snapshot resolution of dependencies, plugins, etc.

If a user's build is broken by the most recent snapshot, rolling back would be a great option, if available.

  • Binary artifact promotion/certification to transition to/from QA, RC, etc. status

It would be good to have a process to support releasing something into QA with the possibility of having that artifact promoted to other testing stages in binary form, or certified from RC to real release. Conversely, if a problem is found, to reverse the release progression back to SNAPSHOT status.