It's not possible to know that at build time though. The incompatabilities might be created programatically at runtime. This responsability falls with the developer to do proper testing before integrating new technologies into your code. Sure it would be nice if Maven told you where you'd gone wrong, but that isn't the job of a build tool.
On 13 April 2011 13:50, Tom Eugelink <[email protected]> wrote: > Correct, what I am looking for is Maven to tell me there is a version > conflict. > > > > On 13-4-2011 14:22, Benson Margulies wrote: > >> Adam, it might not be *his code*. He writes something that uses the >> newest, spiffiest, version of component X. Then he adds a dependency >> on component Y. And, buried in the transitive dependency graph of Y is >> an ancient version of X. >> >> Yes, of course, we could tell him to use OSGi and all buy shares in >> companies selling perm gen space. >> >> The point here is not to try to make these cases *work*, it is to >> diagnose, since in the worst case the failure modes are complex and >> confusing. >> >> On Wed, Apr 13, 2011 at 8:17 AM, Adam Gibbons<[email protected]> >> wrote: >> >>> 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] >>>> >>>> >>>> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- > > *Tom Eugelink* > Senior software engineer > +31 (0)6 - 47 93 85 92 > [email protected] <mailto:[email protected]> > *KnowledgePlaza <http://www.knowledgeplaza.nl>* > Sutton 15 > 7327 AB Apeldoorn > Tel: +31 (0)55 - 526 3887 > Fax: +31 (0)55 - 526 3950 > [email protected] <mailto:[email protected]> > Disclaimer: The information contained in this message is for the intended > addressee only and may contain confidential and/or privileged information. > If you are not the intended addressee, please delete this message and notify > the sender; do not copy or distribute this message or disclose its contents > to anyone. > > > > > > > > >
