Message-ID: <448102064.799.1411034024968.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_798_1204288777.1411034024968" ------=_Part_798_1204288777.1411034024968 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Need more information here about specific design problems with version r= anges.=20
Currently, there is only one implementation of conflict resolution in Ma= ven. In certain cases, users may wish to use alternative methods to resolve= these conflicts, maybe even opting to fail the build when a conflict is de= tected.=20
These different resolution techniques may not be mapped 1:1 with a given= POM. Instead, it may make more sense to allow the user to configure his ow= n preferred strategy, in order to make his role in the development effort s= impler. One such example might be QA testers, which may opt to verify that = all dependencies are convergent before proceeding with what may be an irrep= roducible build.=20
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.=20
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.=20
If a user's build is broken by the most recent snapshot, rolling back wo= uld be a great option, if available.=20
It would be good to have a process to support releasing something into Q= A with the possibility of having that artifact promoted to other testing st= ages in binary form, or certified from RC to real release. Conversely, if a= problem is found, to reverse the release progression back to SNAPSHOT stat= us.