Message-ID: <2004739287.8971.1413853713331.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8970_748997822.1413853713331" ------=_Part_8970_748997822.1413853713331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The current version scheme for Maven 2.0 of=20 =20
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
appli= cation requires that the corporation has access to the source
code o= f 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 package= d by that organization or a known integrator.
Existing packaging mechanisms such as RPM provide the capability of a vendor tag.=20
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 <= br /> 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 w= hole string is viewed
<build>are exclu= sive. 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=20
In adding these addition requirements, it is important to keep in
= mind the existing version scheme which is good for casual use of
li= braries 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:=20 =20
This tag if present in a version dependency would be the most binding. A specification of
[3.1.0:myvendor-SNAPSHOT] would requir=
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 =
essentially correlating 'service packs' to a specific buil= d number.
With the presence of a vendor qualifier, this allows the v= endor to
define what each build number represents.
Putting this altogether, we can specify the version dependencies for
the examples as follows:
(exactly 3.1) =3D
(3.1 built by us) =3D
(3.1 built by us and sp2) =3D
correlates to build 2)
(3.1 built by us and at = least sp2) =3D