crazy idea, but why don't you just refactor the code that only works with v1.0 to work with v2.0? it might be better anyway...
On 13 April 2011 13:15, Benson Margulies <[email protected]> wrote: > 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] > >
