This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Extending Maven 2.0 Dependencies
Skip to end of metadata
Go to start of metadata


The current version scheme for Maven 2.0 of


is suited for versions up to and including a project's
release, but additional identifiers are recommend for vendor
identifiers and post-release versions.


Vendor Tag

Oftentimes to use an open source project within a corporate
application requires that the corporation has access to the source
code of a given project release and that the library is reproducible
from this source code. Many development organizations have the
compliance requirement that these libraries can be identified as
being packaged by that organization or a known integrator.

Existing packaging mechanisms such as RPM provide the capability of a
vendor tag.

We propose that Maven dependencies be able to be specified based on
the identification of a vendor.

Post release

In addition to the vendor tagging requirement, a library can often go
through multiple patches before a new release is published by the
original project team. Even in the case where the release lifecycle
is short, it is inevitable that production issues will occur between
releases that need to be addressed, and a library incorporating a fix
needs to be issued. These fixes can be aggregated and the source
rebuilt by the user of the library or third party support provider.
The resulting library then needs identification as being of a certain
patch level or 'service pack'.

To make this concrete in terms of a Maven user let us look at some
dependency cases on the Apache Commons Logging project:

  • (exactly 3.1)
  • (3.1 built by us)
  • (3.1 built by us and sp2)
  • (3.1 built by us and at least sp2)

Current Design

  • Currently, the <major>.<minor>.<revision> component of a
    version must be numeric; if non-numeric characters are used to
    annotate this (e.g. 3.1.0myvendor-01), the whole string is viewed
    as a qualifier.
  • <qualifier> and <build> are exclusive. Hence one can't
    specify [3.1.0-myvendor-01].
  • <qualifier>'s main purpose is for pre-releases (i.e. alpha,
    beta, rc). From a release timeline, the qualifier is lexographically
    compared, with no qualifier having the greatest value. So 3.1.0-
    alpha < 3.1.0-beta < 3.1.0-rc < 3.1.0-sp1 < 3.1.0. The desired
    behavior would be that 3.1.0-sp1 > 3.1.0

Alternative Designs Considered

Three sub-optimal alternatives to handle the vendor tag requirement
in the existing version scheme have been considered

  1. Alter groupId or artifactId to include the vendor's tag. An
    artifactId of commons-logging becomes commons-logging-myvendor. This
    has the effect of bubbling the version dependency up.
  2. Restrict the Maven remote repository only to those which contain
    artifacts built by a vendor. With this scheme no metadata about the
    vendor is possible in the local repository. It's a very tenuous
    dependency at best
  3. Exactly specify the vendor tag and release (e.g. {{[3.1.0-myvendor-
    sp1])}}. Effectively this treats the whole string as a qualifier
    and does work for that specific library, but one loses all ordering
    relationships. You can't specify [3.1.0-myvendor-sp1,3.1.1) with
    this scheme.

For handling post release versions an alternative would be

  1. Use the build number to represent a patch release or service pack.
    commons-logging-3.1.0-03.jar would in this case be presumed to be
    different than commons-logging-3.1.0-01.jar and contain the
    additional fixes and patches. While this could work, it's not
    explicit that the build number correlates to additional patches.


In adding these addition requirements, it is important to keep in
mind the existing version scheme which is good for casual use of
libraries from an existing Maven repository like iBiblio. Thus we
don't want to break backward compatibility.

For handling the vendor tag requirement we propose a vendor qualifier
tag to the existing version:


This tag if present in a version dependency would be the most binding.
A specification of [3.1.0:myvendor-SNAPSHOT] would require that
the snapshot used must have that 'myvendor' identifier.

In conjunction with this vendor qualifier tag, it may be acceptable
to use the [-<build>] to distinguish follow-on patch releases,
essentially correlating 'service packs' to a specific build number.
With the presence of a vendor qualifier, this allows the vendor to
define what each build number represents.

Putting this altogether, we can specify the version dependencies for
the examples as follows:

(exactly 3.1) = [3.1]
(3.1 built by us) = [3.1:us]
(3.1 built by us and sp2) = [3.1:us-02] (assuming sp2
correlates to build 2)
(3.1 built by us and at least sp2) = [3.1:us-02,3.1.1:us)

  • No labels


  1. I wouldn't like to use <major>.<minor>.<revision>vendortag(-&lt;qualifier>|[-
    <build>]) as content of the version tag. It has more sense having a <vendortag> element in the dependency.

    1. I think I agree with Carlos here, won't the repository imply the vendor?

  2. it's worth noting the original use of the build part is for these (not the snapshot build). Making that a string instead and somehow denoting which are pre-release (snapshot, alpha, etc) and which are post (us-01, b02) sounds like a good extension

  3. I'd like to propose another, possibly more flexible solution.

    First, the ":" might pose some problems; the g:a:v scheme is sometimes also written as g:a:classifier:v, so having a colon in the version might cause problems.

    We could somehow specify a versioning scheme in either a root pom, or some other repository metadata file. This version scheme would specify all the fields that make up a version string; perhaps even a regular expression to split those strings up. This way, random schemes can be used, and maven can correctly apply version ordering.