Message-ID: <1922020060.4801.1369467778327.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4800_967612792.1369467778327" ------=_Part_4800_967612792.1369467778327 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Currently, Maven supports the resolution of artifact versions by way of = nearest-wins. That is, for any set of dependencies that share the same grou= pId:artifactId:typeclassifier in a p= articular artifact closure, the one declared nearest to the current project= in the dependency tree will be selected for use. This can lead to subtle e= ffects, where upgrading a particular version of one dependency in your POM = can lead to a transitive dependency being declared nearer than previously, = and therefore changing the version used for that transitive dependency.
While this approach to conflict resolution is probably at least as good = as any at solving the problem generally, it's important to recognize that c= ertain situations may call for very different conflict resolution methods.<= /p>
The following scenarios describe times when specific conflict resolution= techniques may be used to address specific problems.
In this scenario, users will likely want to know if there is any disagre= ement on dependency versions. Any disagreement could be used to spot-check = the full application for features that may express incompatibility with the= chosen version of the artifact.
In some cases, these builds might be allowed to proceed with simple warn= ings about version conflicts. In others (particularly when the application = is thought to be ready for a production rollout), it would be highly desira= ble to have the build fail if a conflict is detected, since any conflicts s= hould have been resolved manually in the POM during testing or earlier.
Alternatively, it's possible that a testing team wouldn't want to adjust= upstream dependency declarations, and wouldn't want to impact the purity o= f the application POM's dependency specification. In these cases, they want= the dependency list to converge on a set of "blessed" versions w= ithout allowing the build system any leeway to decide (with a potential to = decide incorrectly) on its own.
Nightly and integration-style builds will likely take place on a CI serv= er, and should sometimes incorporate a build of all the latest artifacts wh= ich match the specified dependency list. This way it's possible to report o= n possible migration/upgrade paths for POMs in the build that are not using= the latest matching version.
Many companies keep tight control over which external dependencies they = allow for the software they produce. This can take many forms, from auditin= g and approving individual artifacts as they are added to a corporate repos= itory, to auditing builds during testing, etc. In these situations, it migh= t be useful to impose a conflict resolution technique to enforce the usage = of a blessed set of artifact versions in a given build. This would allow ot= her groups in the company to vet each artifact version before putting it on= the blessed list.
In this case, non-compliance would likely result in a broken build.
In some special cases, it may be useful to override the version resoluti= on process altogether, and instead use some alternate artifact version. One= such scenario might involve generating migration reports for each of a set= of projects. These reports might let developers know what sorts of problem= s they'd be likely to confront if they tried to move their application from= its existing dependency-version set to the latest-and-greatest set. To mak= e these more useful, it might be good to restrict the version override to a= single dependency at a time, to isolate the errors related to that depende= ncy upgrade.
Maven's artifact-handling components have the current version conflict r= esolution strategy hard-coded in place. The current strategy has to be comp= onentized and abstracted to an interface so that we can switch strategies.<= /p>
Beyond this, we need to provide a mechanism for configuring the desired = conflict resolution technique. For most purposes, it might be best to confi= gure a Maven instance to use a particular technique, assuming that= testing users, pre-production users, and CI systems will always look for t= he same type of conflict resolution technique.------=_Part_4800_967612792.1369467778327--