2008/12/8 Ian Robertson <[EMAIL PROTECTED]>: > On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: >> On Thu, Dec 4, 2008 at 11:06 AM, Ian Robertson <[EMAIL PROTECTED]> wrote: >> > I would propose that the semantics change to "Of the overlapping ranges, >> > the *lowest* soft requirement is the version to be used." Consequently, >> > new releases of a project would not change builds of other projects >> > depending on it (assuming that version numbers increase instead of >> > decrease with each release). This would negatively impact those projects >> > wanting to live on the "bleeding edge", but benefit projects wanting >> > repeatable builds. In practice, range syntax does not appear to have >> > gained much traction to date, so this change would hopefully not have >> > substantial impact in terms of backwards incompatibility. Moreover, >> > providing semantics which do not introduce instability might increase >> > adoption of the syntax. >> >> I think the short answer is, if you want repeatable builds then don't >> use range syntax. >> By defining a range you are saying that everything that fits in this >> range is a valid choice. >> Even those in the future that have yet to be release, as long as they >> fit in the range. >> Given that these future versions dont exist they haven't been tested >> so using a range can be dangerous. > > You raise a good point - open-ended version ranges leave one vulnerable > to backwards-incompatible library upgrades. But the current strategy of > taking the highest version introduces an additional element of > instability to application that can appear from one day to the next > without any change to an applications code base. > > Unfortunately, without a notion of version ranges, managing versions > becomes prohibitive in projects with large dependency graphs. If an > application has several different transitive dependencies on a > particular library, the application developer is forced to traverse the > entire graph, examine all the dependencies, and choose the highest of > them so that she is guaranteed not to hit NoClassDefFoundErrors or > NoSuchMethodErrors at runtime. For projects with hundreds of transitive > dependencies, this is error-prone at best. Version ranges allow each > module to declare the minimum version it needs to run properly, and let > maven do the work of finding a version acceptable to all modules in the > dependency graph.
Isn't it the purpose of dependencyManagment to help in such a case? > >> There is talk about a plugin (can't recall which) that can lock down >> the version of plugins and also tell you if newer versions are >> available, so you can selectively decide to upgrade. But I am not >> sure if such a plugin exists yet. > > The versions-maven-plugin looks useful, but doesn't appear to address > transitive dependencies which are never mentioned in an application's > pom.xml. That's one of the main issues I'm trying to solve. > > > CONFIDENTIALITY NOTICE: This message is intended only for the use and review > of the individual or entity to which it is addressed and may contain > information that is privileged and confidential. If the reader of this > message is not the intended recipient, or the employee or agent responsible > for delivering the message solely to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify sender immediately by telephone or > return email. Thank you. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gilles Scokart
