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.
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
We propose that Maven dependencies be able to be specified based on
the identification of a vendor.
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:
<major>.<minor>.<revision>component of a
3.1.0myvendor-01), the whole string is viewed
<build>are exclusive. Hence one can't
<qualifier>'s main purpose is for pre-releases (i.e. alpha,
Three sub-optimal alternatives to handle the vendor tag requirement
in the existing version scheme have been considered
For handling post release versions an alternative would be
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 built by 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) =