I do find it surprising that your saying declaring a dependency is *only a wish*? A declared dependency *should be* closest to the root, our do you make your declarations in a Parent POM?
We too used to *factor up* any shared dep to the Parent but have stopped since it creates a couple of issues, yours being just one of them. > 2.Use Dependency Management. In my parent pom I can declare all > dependencies and their versions. Advantage: I have full control of > the dependencies in the child moduls. Disadvantage: If I need to > change a version of a particular dependency, I need to release a > new version of the parent pom and afterwards I have to update the > version number in all child projects which need the new version of the dependency. If you are declaring versions in depMgmnt, don't put a version in the project pom dependency. Work with a SNAPSHOT POM version until you have what you want, then RELEASE it, to nail it down. I don't advocate version ranges at all since your build may not be re-produceable if you do. ________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -----Original Message----- From: Michael McCallum [mailto:[email protected]] Sent: Tuesday, September 28, 2010 5:51 PM To: Maven Users List Subject: Re: What is your strategy to manage dependencies? I highly recommend using version ranges, in fact i wonder how people work without them, it must be really hard to keep track of all the dependencies. On Wednesday 29 September 2010 10:29:36 Mario Wirth wrote: > Thank you Antonio, > for your response. But is this really the only solution? Is there no > plugin or technique available which helps to avoid (binary) > compatibility conflicts between artifacts? > Can anyone recommend the use of version ranges? > > Thanks, > Mario > > Am 24.09.2010 09:47, schrieb Antonio Petrelli: > > 5. Use released versions if possible and resolve conflicts one by one. > > > > Antonio > > > > 2010/9/24 Mario Wirth<[email protected]>: > >> Hi community, > >> > >> I am interested in your strategy, how to use Maven to make sure, > >> all artifacts are selected in the right version. > >> > >> By default, if you add a dependency with it's version, that is only a wish. > >> Maven is allowed to change the artifact to a newer or an older > >> version. It depends on the dependency tree and the distance to the root. (see: > >> http://www.sonatype.com/books/mvnref-book/reference/pom-relationshi > >> ps-sect-project-dependencies.html#pom-relationships-sect-version-ra > >> nges) > >> > >> As a consequence, sometimes my war file contains libs which do not > >> fit together. The following solutions I've figured out so far: > >> 1.Declare all needed dependencies in the pom of the war file. Disadvantage: > >> I have to do the work manually. > >> 2.Use Dependency Management. In my parent pom I can declare all > >> dependencies and their versions. Advantage: I have full control of > >> the dependencies in the child moduls. Disadvantage: If I need to > >> change a version of a particular dependency, I need to release a > >> new version of the parent pom and afterwards I have to update the > >> version number in all child projects which need the new version of the dependency. > >> 3.Use Version Ranges. Advantage: With version ranges I can add more > >> specific informations for Maven. This is used to support the > >> conflict resolution and maven only selects artifacts which satisfy all version ranges. Advantage: > >> conflict resolution does not cause (binary) incompatibilty between > >> the artifacts, if the version ranges are set correct. Disadvantage: > >> There is more effort during the release process: you need to build > >> a release pom with resolved version ranges to make the build > >> repeatable. You have to hide Snapshots during the release process, > >> if you use boundaries like [4.0,). And finally, maven needs > >> additional meta data from the repository. If the meta data are not up to date, strange behaviour can happen. > >> 4.Use only snapshots. If I use only snapshot versions, the latest > >> version is always used. Disadvantage: Developing against snapshots > >> can be frustrating because of the nature of snapshots ;-) But you > >> will find out very fast, if something is binary incompatible. > >> > >> So, I am very interested in the best practise! How do you solve the > >> problem to manage all dependencies in their correct version. Thank > >> you for your suggestions in advance. > >> > >> Mario > >> > >> ------------------------------------------------------------------- > >> -- 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] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
