Hi Ian, Ian Robertson wrote at Montag, 8. Dezember 2008 20:35:
> On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: [snip] >> 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. Nothing can really keep you save from such incompatibilities and problems anyway. You silently imply that a higher version is always compatible, but that's also not true (you know). In really worse cases it is like the incompatible ASM 1.x, 2.x and 3.x series, but even for such an innocent upgrade from JUnit 3.8.1 to 3.8.2 you might get a surprise, because the latter uses a method not available in JDK 1.3 runtime. And this does not cover cases where the groupId for the artifact changes (e.g. xstream:xstream:1.1.3 com.thoughtworks.xstream:xstream:1.2) or artifacts are splitted and/or renamed (e.g. avalon:avalon-framwork:4.1.4 to org.apache.avalon:framework-api:4.3.1 and org.apache.avalon:framework-impl:4.3.1) or two artifacts deliver the same classes (commons-logging:commons-logging:1.1.1 and org.slf4j:slf4j-jcl:1.5.6) or a jar is consumed by a different one (e.g. org.ajax4jsf:ajax4jsf:1.1.0 into org.richfaces:richfaces:3.1.0) or consumed even by the JDK (javax.activation:activation:1.0.2 in JDK 6). Therefore it is always the developers task to take care of the complete dependency tree of a product/project. [snip] - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
