Skip to end of metadata
Go to start of metadata

There has been a few quoted use cases for using an alternate way to locate artifacts, rather than using a repository. For example:

  • gentoo packagers
  • gump
  • as an alternative to file based jar overrides

The situation is that in each case there is already a way for them to obtain a complete set of artifacts for a project that are built, verified, signed, etc.

While a workaround is to use a file based repository, structure in the Maven way, this might be too inconvenient.

Icon

Given there is a workaround, this may be something we delay until Maven 2.1, but if it can be facilitated while the artifact code is being cleaned up, that'd be great)

The questions to resolve:

  • is just a custom repository format required (and they still provide poms, etc), or do they need their own resolver
    • we will encourage different wagons, but maven-artifact should stay the same
  • should repository formats be pluggable? Via configuration, or code additions?
    • too risky, no need
  • should the resolver be more pluggable? Does the design of the current one do most of the real work under the covers so it can be replaced safely without losing functionality (like transformations)?
  • how should users alter components used in maven? Do they provide a plexus.xml/components.xml file as part of their m2 installation?

For this, we will work with those that need it (in particular the linux distros) to see what they want, what compromises we can reach to get it working. Maven's architecture should be unaffected.

  • No labels

2 Comments

  1. Our corporate build environment already has a solution for dependency resolution, but we would very much like to start using Maven2 for the wealth of other features it provides.

    Therefore, we need to integrate Maven2 with our existing system for dependency resolution, and perhaps later introduce a central Maven2 repository, once the other benefits of Maven2 are more apparent to everyone.

    If we don't care about automatic transitive dependencies, would it be possible to override the Maven2 dependency resolution mechanism to map to our custom JAR names at custom project-relative filesystem locations?

    We are happy to write the custom dependency resolver ourselves, just need to make sure it can be achieved.

    Kind Regards.

  2. Similarly, Maven needs to support repositories based on configuration management and/or version control systems. In particular, users of such systems do not want version numbers in the file names, since this stops them from using configuration management properly.

    For example, a ClearCase-based repository could operate in 1 of two modes:
    1) no JAR versions are specified, each user picks up the view in the ClearCase view they are using;
    2) JAR version is used as label to pick a version of a JAR file with no version in its name.
    For Subversion or CVS, it might similarly be that:
    1) JAR version is used as tag to pick a version of a JAR file with no version in its name;
    2) JAR version is used as branch name to pick a version of a JAR file with no version in its name.

    My question: do the maven-artifact and wagon (wagon-scm) interfaces provide the necessary support to allow such implementations?