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]
