Hmmmm.... you've just given me an idea for a mojo for the versions-maven-plugin
http://jira.codehaus.org/browse/MVERSIONS-16 2008/12/11 Chris Maki <chrism...@mac.com> > Hi Everyone > > In the spirit of full-disclosure, I work with Ian at Overstock.com, but I > wanted to chime in on this discussion because of issues I've had with > various projects. > > Given this scenario: > > com.foo:my-artifact:jar:1.0:compile > org.hibernate:hibernate:3.1.1:compile > com.foo:another-artifact:2.0:compile > org.hibernate:hibernate:3.1.3:compile > > I would like to see a way for com.foo:my-artifact to suggest hibernate > 3.1.1, at the same time, indicate if there is another version of hibernate > in my dependency tree (not in all of maven, just my dependencies) which has > a higher version defined, use it instead (org.hibernate:hibernate:3.1.3 in > this case). Currently, the closest I can get to this is the range syntax, > [3.1.1,) but as we all know, this syntax will download the latest version of > hibernate (today this would be version 3.3.1.ga). > > I agree that developers should be responsible for managing their > dependencies, at the same time, Maven should make things easier not more > difficult. If I have 150 dependencies, how much time should I spend > determining which artifacts should be included? Perhaps as much time as > needed; however, If there was a way to indicate "use the highest declared > version" of a common dependency then Maven would be assisting me in managing > my dependencies. > > Does it seem like a bad idea to have a syntax that lets the highest > dependency version within my project dependency graph win, IFF I had a way > to indicate this preference? > > Thanks > > Chris > > > On Dec 9, 2008, at 12:25 AM, Jörg Schaible wrote: > > 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: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
