Michael McCallum wrote: > On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: >>> project.deployable uses implementation.[1,2-!) and consumer.[1,2-!) >>> obviously in the real world things aren't this simple and for >>> simple cases this seems like excessive overhead >> >> We do not use ranges at all. Works great without. > > Define great... You have no real definition of a build... its > transient as saying i would like something that kinda resembles 3.4.5 > of > an artifacts does > not really mean much at the end of the day. It would be > possible for maven to > resolve 2.0.5. (just look at our xml apis/xerces versions in > dependency:tree)
This is not true. Since we define the version (no range) in the depMgmnt, this will superceed also the inherited versions and Maven has not really to do any version resolution. > where as saying i can only use any 1.X version of an artifact > is a lot more > constraining. I would never get a deliverable which had > version 3, or 2 etc. What do I have from the range definition at all? If I build two EJBs and one refers commons-collections 3.1 and the other one commons-collections 3.1.1 in its manifest's class path, the resulting EAR is broken since one EJB is referencing a not available jar. It does not help me that both EJB can run with both versions of commons-collection. Without the range I will get either 3.1 or 3.1.1 - depending on what I selected in the global master pom. > For the same reason that static type checking is good so are ranges. If it does not resolve to the same artifact inthe end, it will help you nothing. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
