On 8/9/06, Mike Perham <[EMAIL PROTECTED]> wrote:
Again, this is because dependency B is not using version ranges but rather forcing a specific version on its downstream dependents.
Thinking about this a little further, there is a QE viewpoint that leads me to believe that declaring a specific version on a dependency is actually the right thing to do. Let's consider a concrete case: the Shale core library (org.apache.shale:shale-core) artifact depends on, among other things, Commons BeanUtils. In the POM for this module, I want to inherit from the parent POM (org.apache.shale:shale-parent) a dependence on a particular version of this library, so that I can update the dependencies of a bunch of other artifacts all at once when I've satisfied myself that it works. Currently, in the parent POM, the version (declared in a <dependencyManagement> section) of BeanUtils that is requested is, specifically, "1.7.0". This is essentially an assertion that I have tested my library against this specific version, and am satisfied that it works. If I understand your recommendation correctly, you would like me to declare my dependency on version "[1.7.0,)" instead (meaning "version 1.7.0 or any later version"). From a QE perspective, that is an untestable assertion -- there is no way to know that some future version of BeanUtils might introduce some incompatible change that makes *my* library no longer work. That is not acceptable to me as the supplier of a library, because it is *me* who is going to suffer the "you *said* it would work" bug reports. If an end user of my library wants to override my setting, they can (although making them do it in every leaf node is definitely a violation of the "don't repeat yourself" mantra that M2 seems to really like :-). But I want *my* POMs to advertise what *I* have tested, and not rely on all of my dependencies not to break me with future versions. I wouldn't even want to trust my own modules enough to use ranges like that :-). Craig
