Jörg, The question is, "Are there interesting cases in which the author of the package knows that 2.0 is absolutely not compatible with the previous reasons?" Or, at least, knows that it's very rarely going to be compatible?
Imagine that, as part of deploy, the author could attach a bit of metadata that had these semantics. Just in case, those semantics could be read by the enforcer instead of by the maven core. As it is, the OP needs a pretty good crystal ball to come up with a comprehensive enforcer config of all the possible ancient versions in transient dependencies (or there other way around) that could cause havoc. --benson On Wed, Apr 13, 2011 at 8:10 AM, Jörg Schaible <[email protected]> wrote: > Benson Margulies wrote: > >> The OP wishes that maven had some, ahem, declarative mechanism for >> raising a flag in this case. No guessing. Some way to attach metadata >> to 2.0 that says, 'you can't use this as a compatible replacement for >> 1.0. Yell instead.' > > Yeah, I know, but in my case, I don't want a yell, simply because I can use > 2.0 as compatible version. Therefore, if this "compatibility" declaration is > delivered by x:y:2.0, it does not make sense. If I should be able to declare > it for my app, I could already use the enforcer instead. > > - Jörg > >> >> On Wed, Apr 13, 2011 at 7:51 AM, Jörg Schaible >> <[email protected]> wrote: >>> Benson Margulies wrote: >>> >>>> There is perhaps a communications problem here. I don't think this is >>>> about ranges. I suspect that it is about: >>>> >>>> - project g:A version 1 depends on x:y:2.0 >>>> - project g:B version 1 depends on g:A:1 and x:y:1.0 >>>> >>>> What ends up in the classpath of B? x:y:2.0, I think. >>> >>> So what? Should or can Maven now somehow detect that g:B uses stuff of >>> x:y:1.0 that is no longer available in x:y:2.0? If it does not, it is not >>> helpful at all, if some mechanism ensures that g:B runs with x:y:1.0 >>> only. >>> >>> - Jörg >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
