In this situation I would simply not allow A to depend on C-1.0.0. I'd upgrade to C-2.0.0 for all modules and deal with whatever change A had to swallow to sustain that.
Less surprises, problems found earlier. I haven't encountered a situation where it would be beneficial to do otherwise yet. Using dependencyManagement in a parent pom is just following DRY. I'm not saying version ranges can't be a useful way of working, I'd just prefer to be sure of what was being delivered. We do have a huge battery of automated acceptance tests running under CI so we can afford to upgrade drop in replacements often with low risk. Cheers Brian On 30 September 2010 00:07, Mario Wirth <[email protected]> wrote: > Sorry, for the misleading post. I declare all dependencies, which are > needed for compile in the project's pom (not parent pom). I trust on maven's > conflict resolution and don't use Dependency Management at all at the > moment. The reason for that I have described already: I don't want to > release the parent pom and update the new version number in each child. If I > don't do that, former builds are not repeatable. > > But if you trust maven's conflict resolution, it can lead to the following > situation: > There are 3 projects and their releationship: > > A-1.0.0 → B-1.0.0 → C-2.0.0 > In addition A as the following dependency: > A-1.0.0 → C-1.0.0 > > If project A is a war, it's lib folder will include B-1.0.0 and C-1.0.0. > But B-1.0.0 needs classes which are only available in C-2.0.0. Consequence: > You will get an exception at runtime. > > With version ranges you can avoid that. You have to write in the POM of B → > C[2.0.0, 2.1). Maven will consider this additional information and select > version C-2.0.0. > > But version ranges lead to other problems. You need correct meta-data and > you have to create a release pom to resolve the version ranges at release > time. (see: > http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html > ) > > I really would like to use version ranges, but I read very often in this > forum: Avoid version ranges! (the post of Michael McCallum is an exception > ;-) ) I am not sure if it's the maven way. > On the other hand: If you do the dependency management manually, you use > Maven just to download the artifacts. Is that the maven way? > > Thanks, > Mario > > Am 29.09.2010 15:27, schrieb Yanko, Curtis: > > >> 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] >> >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
