> IOW, whatever is specified in the POM file of individual projects is > likely to be overridden anyway and the best the could be done > is to avoid known gaping incompatibility holes (of which I'm not > aware of too many).
Fair enough, but Guava is a particular problem. Map eviction listeners completely change somewhere between r09 and r11. It could theoretically be possible to handle that with reflection but that would be a lot of reflection, in performance sensitive code paths, and likely to fail only at runtime/in production if there is a mistake or another change. So all of Hadoop should get on the same page with this. Sadly I see Giraph just moved to 12 while everyone else is on 11. On Sat, Jun 30, 2012 at 7:17 PM, Roman Shaposhnik <[email protected]> wrote: > On Sat, Jun 30, 2012 at 5:24 PM, lars hofhansl <[email protected]> wrote: >> So will Guava 11.0.2 in hbase 0.94 be a problem? Should we not update Guava >> (at least not until 0.96)? > > In general, I don't think there's good answer to how dependencies > are supposed to be managed wrt. version numbers. After all, all > of the Hadoop ecosystem projects have to deal with the fact that > there's at least half a dozen different branches of Hadoop they have > to work with. It is virtually guaranteed that whatever you do you will > end up incompatible with one of those builds and most likely the > version of a dependency that wins will be the one that Hadoop is using. > > IOW, whatever is specified in the POM file of individual projects is > likely to be overridden anyway and the best the could be done > is to avoid known gaping incompatibility holes (of which I'm not > aware of too many). > > Thanks, > Roman. -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
