Hello Stephen, thanks for your reply, more inlined.
On Thu, Feb 2, 2012 at 5:29 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > On 2 February 2012 16:17, Leon Rosenberg <rosenberg.l...@gmail.com> wrote: >> Hello, >> >> I have following question, I don't quite understand how to solve >> properly. I have 3 projects, A,B and C. >> A depends on B and C, and B depends on C. >> >> A requires at least C version 1.06. However, after a while C got a new >> feature which is now used in B. So in my situation A contains: >> B version 2.0 >> C version 1.0.6 >> >> pom of B (2.0) contains >> C version 1.0.14 >> >> When I build A, I'd expect 1.0.14 of C to be included through the >> dependency to B. However, the resulting war contains 1.0.6, which >> cause B 2.0 to malfunction, because it expects 1.0.14 of C. >> How can I resolve this issue, without manually version of C in the pom of A? > > two solutions immediately present themselves: > > 1. Remove C as a dependency from A (transitive will pull it in) yes, this will probably work, but wouldn't it be silly to have dependencies not clearly stated? We had a similar issue a while ago, project X used project Y, which relied on struts, which relied on commons-validator. Than we updated the dependency to Y to 2.0 instead of 1.x something. What we didn't know, is that the dependency to struts was removed (or set as provided) in project Y. Now our code in project X, which was using EmailValidator from from commons-validator stopped building, and we spent a lot of time trying to track the change that broke the build. > or > 2. Make B depend on C [1.0.14,) > > Note for option #2, most people consider version ranges evil, as they > can cause non-reproducible builds and only really work when people use > the major.minor.patch 3 segment version numbers without qualifiers. I think, since we control both, B and C, option 2 seems like a lesser evil.But we will have to test it! > > I'd go with option 1. > > If B ever decides to remove its dep on C, then your build of A will > immediately break to tell you ;-) Thats true ;-) Unfortunately its not always easy to find a cause. > >> >> regards >> Leon >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
