Message-ID: <752669772.41532.1371658320313.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_41531_1185013150.1371658320313" ------=_Part_41531_1185013150.1371658320313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
It's possible for a given API to have multiple implementations. For exam= ple, the JavaMail API has the reference implementation provided by Sun, alo= ng 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 JavaMa= il implementation would specify that it provides an implementation of the J= avaMail 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 depe= ndencies from a single build.
In addition, we need a mechanism for providing a provides-ish notation f= or assemblies and other attached artifacts that may contain one or more of = the project's dependencies. For example, if a project's build produces an a= ssembly using the 'jar-with-dependencies' pre-defined assembly descriptor, = it should have some way of indicating to Maven that it already contains tho= se dependencies. This way, it can be used as a substitute for other depende= ncies specified by a user, if those dependencies have the same groupId:arti= factId:version:classifier:type. If there is a mismatch of dependenc= y IDs between those provided by the assembly and those specified directly i= n the user's POM, then the assembly should not be allowed in the build.
Maven currently has a very concrete notion of what constitutes an artifa= ct. In many ways, an artifact is assumed to be a physical, binary file out = on one or more repositories. We have flirted with some forms of virtualizat= ion by supporting snapshot dependencies, RELEASE/LATEST meta-versions for p= lugins, and POM relocations. However, we currently have no way to handle 1:= N mappings of a specified dependency to potentially satisfying artifacts.= p>
Specifically, Maven lacks two things to support this concept:
Once we have these two pieces, the specification-POM becomes simply anot= her layer of metadata, much like a RELEASE version for a plugin.