thirdly version ranges give you deterministic and manageable conflicts. however in the case of spring you should not be mixing the different major revisions that will just give you headaches... use one or the other
1.2.X not compatible with 2.0.X not compatible with 2.5.X, i use version ranges to ensure that no projects cross pollinate... if they do one has to go up or the other down to get a deterministic result. On Tue, 26 Aug 2008 16:06:51 Geoffrey Wiseman wrote: > On Mon, Aug 25, 2008 at 3:40 PM, Farrukh Najmi < > > [EMAIL PROTECTED]> wrote: > > In my project there are many direct and indirect dependencies at the > > lowest level on springframework jars. > > One such dependency requires use of the most recent springframework jars. > > Migrating to latest version of spring is my projects direct dependency > > causes > > problems at runtime with other dependencies which expect older versions > > of apis from spring and its dependencies. > > > > Is there a good way to deal with this dependency hell? If so I would > > appreciate any advice. Thanks. > > Generally, if a project closer to the root pom (fewer number of transitive > dependencies away) calls for a version of the same dependency (same group > id, artifact id) as a dependency farther away (greater number of transitive > dependency hops), the former will be used to the exclusion of the latter, > as I understand it. I find this solves the vast majority of the problems > right there. > > A secondary mechanism is dependency management, where you can lock in > versions of dependencies using the POM. I find this primarily useful at > not requiring versions to be specified in sub-projects with a master POM. > > Finally, when you have issues where an artifact has been moved/renamed you > may need to get into exclusions. > > - Geoffrey -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
